Professional Documents
Culture Documents
Freebsd
Freebsd
Instalação do FreeBSD:
Existem várias maneiras de bootar o seu sistema para a instalação do FreeBSD, mas
trataremos, nesse documento, apenas das duas maneiras mais usuais.
A Primeira forma de bootar seu sistema, e mais recomendada caso seu sistema permita,
é bootar pelo CD, para isso basta configurar o Setup da BIOS da sua placa mãe para
procurar pelo boot primeiro no CD. A maioria das placas mães mais atuais permitem esse
recurso.
A segunda maneira é a mais comum de todas, e é a que será dada mais ênfase, que é o
boot por disquetes. No próximo Item você vai saber como e onde criar seus discos de boot,
mas nesse momento, vamos aos fatores práticos...
Com os discos de Boot na mão, você deve configurar o Setup da BIOS da sua Placa Mãe
para procurar pelo Boot primeiro no Drive de disquetes (normalmente tido com A:\, floppy,
ou apenas A no Setup da BIOS), então iniciar seu Sistema com o disco do 'kern.flp' para o
primeiro Boot.
Você verá o seu sistema bootando, algumas informações sobre seu Sistema e Sobre o
Boot do sistema a ser instalado serão mostradas, e, após o final, o sistema pedirá o
segundo disco, chamado de 'mfsroot' (mfsroot.flp). Agoura sim o Kernel do seu sistema
será carregado, e então o boot se completará e o menu de instalação, o sysinstall, será
carregado.
Bem, com as imagens em mãos, a criação dos discos de boot devem ser feitas, no Unix,
com o comando "dd if=kern.flp of=/dev/fd0" e "dd if=mfsroot.flp of=/dev/fd0" ]:-) Pronto...
Eis os dois discos prontos... Esse é um processo simples e conhecido se você está
migrando de outro sistema Unix ou clones. Se você vai fazer seu disco de Boot a partir do
Windows/Dos, você vai precisar do aplicativo rawrite.exe que pode também ser
encontrado dentro do diretório 'tools' nos endereços citados acima, ou em qualquer CD
com distribuições Unix, inclusive no CDRom do RELEASE do FreeBSD, também sob o
diretório 'tools.'
A Utilização do rawrite também já deve ser conhecida da maioria das pessoas que estão
lendo essa documentação do FreeBSD, mas a sintaxe deve ser: "rawrite -f kern.flp -d a -n"
e "rawrite -f mfsroot.flp -d a -n" ou simplesmente digite rawrite e siga as instruções do
prompt.
1 - A primeira é para você pular a configuração do kernel, caso você tenha certeza que
tudo já está certo, diz na legenda... :-);
Não se espera que ninguém que esteja disposto a usar essa documentação da EEVIAC
seja um expert em hardware, mas queremos deixar claro que se você está vindo de um
outro sistema Unix qualquer, e ainda não aprendeu a conhecer ao menos o Hardware que
você tem em casa, eis a grande oportunidade da sua vida para descobrir as interrupções
(IRQs) e DMA's (acesso direto a memória) do seu Modem, Placa de Som, Vídeo, Mouse,
Unidade de fita... ]:-)
Bom, mas para não criarmos longas dores de cabeça logo no início, vamos pular essa
pré-configuração do Kernel e escolhermos a Primeira opção: SKIP KERNEL
CONFIGURATION. Porque pular? Você vai ver que é muito mais interessante compilar o
seu Kernel depois da Instalação já pronta.
Pode se acostumar com essa carinha (figura 2)... você vai ver esse menu muito durante
sua vida de Usuário/Administrador de FreeBSD. O Sysinstall é a principal ferramenta de
configuração e administração de recursos básicos no FreeBSD. E eis também a principal
diferença na instalação do FreeBSD em relação a outros Unix e clones de Unix.
É Basicamente um guia de por onde começar a se encontrar nesse menu, fala sobre a
movimentação no Menu (Teclas e Comandos) e do que cada opção vai tratar. Não é
necessários falarmos essas Teclas, uma vez que tudo é bem intuitivo: Setinhas movem
pra cima e pra baixo, tecla de ESPAÇO seleciona ou entra na opção, ENTER confirma ou
alterna o Menu, ESC sai... enfim... tudo bem fácil.
É por onde deve-se começar uma instalação padrão, ou seja, a instalação default, onde
tem um pouco de tudo, e tudo de importante... é a instalação recomendada pelo sistema...
Essa é a opção para inicializar uma instalação personalizada, para os experts, diz o
sistema... Na verdade é necessário um pouco de conhecimento do que se quer para o seu
sistema e o que não é necessário, por isso é recomendada para um usuário já com
alguma experiência, pois pode definir bem o que serve ou não para ele... Essa opção te
oferece a possibilidade de modificar algumas informações do sistema também... deve-se
ter cuidado, e aproveitar ao máximo :o)
Será a opção mais visitada por você depois da instalação: te permite configurar ou
reconfigurar vários dispositivos do sistema, incluindo ferramentas para administração de
usuários, hardware, interface, sistemas e etc;
Permite que você veja e configure várias opções do sistema, algumas delas muito
importantes e que merecem algum cuidado, outras nem tão relevantes... Veremos essas
mesmas opções mais detalhadamente adiante...
Permite que você entre no seu sistema para arrumar algum problema de instalação ou
má configuração que por ventura possa evitar que seu sistema trabalhe eficientemente...
tem a função dos modos de resgate (rescue) de outros sistemas Unix, a tradução direta
desse Item poderia ser: Arrume Isso!
Para você atualizar o seu sistema, caso já exista um FreeBSD mais antigo instalado.
Pede para você adicionar um arquivo via disquete com extensão .cfg que contenha as
informações para que a instalação se faça. Funciona assim: imagine que você,
administrador Unix tenha como salvar as opções básicas das instalações que você faz,
que você nunca mais tenha que selecionar aqueles pacotes um por um, satisfazendo as
suas necessidades, se suas necessidades são sempre as mesmas, e ainda por cima se
pudesse salvar o que você espera dos seus devices e partições em todas as instalações
que você for fazer... pois é... é a possibilidade de fazer isso tudo, que essa opção do
FreeBSD oferece... uma facilidade interessante pra quem sempre precisa fazer instalações
custom.
É um índice de todas as funções que esse menu pode oferecer, fazendo uma breve
descrição da função e já te levando direto para a tela de configuração da mesma... :-)
Para continuarmos com nossa instalação, teremos que escolher entre um dos modos
(Custom, Standard ou Express), e a nossa opção é a Instalação Personalizada. Não que
você deva se sentir o devorador dos Unix (Unices) para instalar em modo Expert, contudo,
nossa intenção é documentar a opção mais completa, então vamos em modo Experiente.
Mesmo porque não esperamos que quem esteja seguindo esse manual, deseje instalar
em modo Express ou uma instalação Padrão... Afinal a comunidade BSD da importância
a coisas que sejam mais que o comum, o padrão. ]:)
Então seguiremos todas as opções do próximo Menu (figura 3). Escolha 'Custom' com a
barra de espaço e analisaremos:
Seguindo a tradução: Faz você sair desse Menu, voltado para o menú anterior que foi
descrito acima...
Lembra-se da opção 1.3.8 na descrição do Menu anterior (acima)? Bem, agora sim
iremos analisa-la de forma mais detalhada:
NFS é o sistema de Arquivos Nativo do Unix, se você for habilitar NFS é bom que ele
esteja em modo seguro, concorda?
Essa opção diminui a velocidade do tráfego de informações na rede NFS, e isso é ótimo
quando não se tem uma rede veloz, com placas de 100mbps e outras desse tipo. Não
adianta sua rede querendo os dados em uma velocidade que as outras maquinas não
suportem, então, para evitar gargalos na rede, foi implementada essa opção. Se sua rede
for de alta velocidade, escolha NO para que o NFS seja o mais rápido possível.
- Debugging: Escolha YES
Vamos escolher YES, porque queremos ter o número maior de informações possíveis
sobre nossa instalação, certo? Dica: Use o segundo terminal (ALT+F2) durante o processo
de instalação pra você ver detalhes do DEBUG da mesma.
- No Warnings: Escolha NO
É importante você ser advertido do que esteja acontecendo de errado com seu sistema...
Mensagens de erro aqui não são como no Windows, uma rotina... aqui deve-se levar a
sério, e serem analisadas.
Adivinha porque? Essa opção marca todas as outras com um SIM. Esse não é o nosso
caso.
- DHCP: Escolha NO
Mesmo se você pretende se conectar via modem a um provedor, essa não é a hora de
startar DHCP no FreeBSD; Essa opção deve ser utilizada se você for instalar o sistema por
rede, e se o endereço IP da sua estação não for definido de forma estática.
Como nossa instalação será feita por mídia comum (CDRom) então essa opção não será
utilizada. Essa opção é extremamente importante se você for instalar seu FreeBSD
remotamente, em rede, via FTP. Se o servidor FTP onde você vai se conectar não aceitar
usuários anônimos, normalmente 'ftp' ou 'annonymous' então essa opção permite que
você defina um usuário e senha válidos para a conexão FTP.
Mante-lo porque é o editor que com certeza você sabe que estará instalado antes de
você portar outros Editores... o VI também faz parte da instalação, mas se o editor default
é o ee, vamos mante-lo então. Faz parte do feeling do FreeBSD;
Você vai usar unidade de fita? Se não, não há porque mudar o tamanho do bloco das
fitas. Mas se for, você saberá quais especificações melhor pra sua unidade de fita de
dados.
Mais uma vez, toda informação possível é bem vinda, então que os detalhes da
extração estejam no nível alto (high);
Pessoalmente não sei se existe algum problema em mudar esse nome, o único
problema que eu pude constatar é que na instalação, apareceu um prompt dizendo que o
nome do RELEASE do FreeBSD que eu estava utilizando não coincidia com o RELEASE
que continha no CDRom, e se eu quisesse que a instalação continuasse mesmo assim...
Várias vezes continuei e outras não... nunca houve diferença, a não ser que algumas
especificações do meu sistema ficavam com o nome de EeviacBSD-4.3, o que eu achava
kitsch. Mas atenção, se você for fazer sua instalação por rede, sem o CDRom, então o
nome aqui deve ser exatamente o mesmo nome do RELEASE que o sistema vai procurar
quando se logar no servidor FTP remoto. Se a instalação em questão for de algum
snapshot do sistema -CURRENT então você deve preencher com algum nome parecido
como FreeBSD 5.0-20001223-CURRENT, que é a versão do snapshot da data em questão.
É Legal utilizar o lynx como browser default, primeiro porque você não tem muita
opção sem portar antes da instalação, e depois, porque faz parte do feeling Unix... lynx, vi
editor...
Porque é o caminho onde o sistema vai procurar o executável do Browser escolhido. ]:)
Se a opção estiver '<not yet set>' ou seja: ainda não configurada, e você apertar a tecla
de espaço em cima, o 'sysinstall' te levará para a tela de seleção de mídia, ou seja, onde
você vai escolher de onde deseja instalar (Partição DOS, FTP, HTTP, Linux, CDRom...).
Nossa opção de instalação é CDROM, então se você selecionar agoura, ou deixar pra
depois, quando chegarmos na Seleção do Tipo de Mídia, não vai fazer diferença! Tudo bem
se escolher agoura ou mais tarde... ];)
É o tempo que o sistema deve esperar (em milesegundos) por alguma informação antes
de retornar uma prompt de erro ou demora... Se você vai instalar por outros meios que
não o CDRom, como via FTP por exemplo, é interessante elevar um pouco esse número,
senão, não há porque seu CDRom não responder em 300ms...
São os comandos para executar quando para criar um Novo File System. Esses
argumentos indicam o tamanho do bloco e inodes.
Se você clicar com a barra de espaço, irá re-procurar e re-analisar os Devices de seu
sistema... você pode fazer o que quiser, não vai mudar muita coisa, a não ser que você
ache que um de seus devices pararam... ou que apareceram outros do nada... enfim, pode
ser interessante se uma interface de rede está iddle e você suspeita que ela tenha caído.
Se você apertar espaço aqui em cima, reseta todas as opções e volta tudo pro original,
destruindo as alterações que você efetuou até aqui.
Depois que tudo estiver pronto, aperte 'Q' para sair ou ESC.
Basicamente a idéia é a mesma do Fdisk do Linux, DOS, ou qualquer outro; Você tem
as partições atuais, e dispõe de comandos para criar novas partições, deletar as antigas,
enfim várias opções disponíveis. Mesmo considerando que o usuário que se propõe a ler
essa documentação já tem certa experiência, vou tentar explicar o que fazer agora de uma
maneira que qualquer leigo (ou quase) possa entender.
Vamos começar pelos comandos disponíveis, os quais aparecem escritos no botton (em
baixo) da tela, como legenda. É importante ressaltar que, a pesar de alguma semelhança
com os Fdisk mais usuais, é necessários sempre ter atenção, pois os comandos não são
os mesmos, e então alguma ação mal planejada pode colocar em risco dados que você não
queira perder.
As setas movem o cursor pra cima e pra baixo na Tabela de Partições.
A tecla 'A' é utilizada caso você deseje que todo o seu disco rígido seja usado para a
instalação do FreeBSD. Essa é a opção mais comum quando se pretende montar um
Servidor com FreeBSD, e a menos utilizada quando vai se instalar seu FreeBSD junto a
outro Sistema Operacional.
Utilizando essa tecla, para ressaltar, todas as partições são ignoradas e sobrepostas
pela partição FreeBSD.
A tecla 'T' muda o tipo da Partição Selecionada. Para explicar melhor: você tem uma
partição alojada como tipo Linux Nativa (ext2fs) e deseja transforma-lo em FreeBSD, e
não quer se dar ao trabalho de deletar a partição e criar outra, então basta apertar 'T'
(todos os comandos podem ser em minúsculas também) e informar o número da partição
a qual ser transformada, no caso de FreeBSD, número 165. Claro que isso pode ser feito
de qualquer tipo para qualquer tipo departição.
A tecla 'G' ajusta o tamanho do Drive. É usado para redimensionar uma partição, caso
o tamanho atual não seja o desejado.
A tecla 'U' desfaz todos as modificações feitas desde que você entrou no FDisk do
FreeBSD.
A tecla 'C' cria uma partição, bastando mover o cursor pra cima do espaço livre alocado,
e apertar 'c'. Então surgirá uma prompt pedindo o tamanho da partição, em blocos, ou em
Megas. Se você for digitar em Megas termine o número com a letra M, em Maiúsculo (ex.:
2048M para dois Gigas de partição).
É bem simples e me ocorreu de colar aqui um exemplo da tabela, mas acho que não é
necessário, ela pode ser encontrada na figura anterior!
Agoura voltaremos ao nosso ponto inicial. Como já dito, para montar o nosso Servidor
FreeBSD, utilizaremos todo o nosso Disco Rígido como partição FreeBSD, então apenas é
necessário digitar a letra 'A' para que a partição FreeBSD seja criada.
Mas, como sabemos que isso não acontecerá com algumas pessoas que estão lendo
esse documento, vamos descrever então o processo de particionamento de discos de
forma a mantermos nosso querido Windows e Instalar o FreeBSD como outro sistema
operativo. E também porque instalar apenas o FreeBSD sem outro sistema operativo é
tarefa mais simples e facilmente assimilada a partir da explicação à seguir.
Então vamos fazer o seguinte: Você se é um usuário precavido e Unix User usual,
normalmente já tem separadinho em seu HD a partição do Windows das outras Unix,
mas se não o tem, é hora pra isso. Faça BackUp de todos os seus arquivos e programas
importantes e que você não possa perder, de Windows, e boote o seu Sistema com um
disco de Boot de DOS. Então utilize de alguma ferramenta de particionamento de discos
para separar o tamanho do seu HD entre o que você pretende deixar para o Windows e o
espaço livre. Essas ferramentas podem ser o Fdisk do Dos, FIPS, Partition Magic... Enfim...
Não faz parte da idéia desse trabalho ensinar ninguém a utilizar ferramentas de
particionamento do Windows. Procure na documentação desses aplicativos. A maioria é
fácil de usar em especial Partition Magic que é seguro além de fácil, podendo oferecer até
mesmo o particionamento sem perda de dados.
1.4.4. Continuando...
Bom, voltando a nossa situação, agora você pode enxergar no FDisk do FreeBSD uma
partição do tipo FAT (escrito 'fat' em 'Desc') com um tamanho (Size) bem grandinho e
avantajado. Essa partição é a do Windows, se ela sumir por algum motivo, digite 'U'
imediatamente, porque não queremos perde-la. Teoricamente.
Obrigatoriamente tem que existir outros tipos de partições também em Desc, ou sejam
unused, ou sejam ext2fs (Linux Nativa) ou Linux Swap; Então você tem a opção de deletar
as partições Linux Nativa e Swap afim de criar espaço livre (unused).
Agoura sim, você opta por criar (tecla 'C') uma ou mais de uma partição. Não se
preocupe nesse momento com a partição de Swap. A gente brinca com ela a seguir. Se
você então tem as duas (ou apenas uma) partição FreeBSD e a sua fat visíveis na tabela,
então basta terminar esse particionamento, apertando a tecla 'Q'.
Em seguida, o 'sysinstall' irá apresentar três opções de Boot para o seu sistema
(figura6). A Primeira opção oferece a instalação do BootMgr, que é o gerenciador padrão
de boot do FreeBSD. É um LOADER do FreeBSD, porém com suas características... Essa
é a opção indicada por nós para a instalação. Marque o BootMgr com a tecla de espaço e
dê [OK].
A Segunda opção, Standard instala o Boot do FreeBSD no setor mestre de inicialização,
sem gerenciar o boot de um segundo Sistema Operacional.
A Terceira opção não faz nada no setor de boot, nem toca se quer, e continua o boot do
Windows ou outro que estivesse alocado na mbr; É o ideal se a intenção é bootar o
FreeBSD por disquete.
Mas se você quer sentir o gostinho de ser Expert logo, e deseja criar você mesmo seus
Swap e UFS, então basta saber que as teclas (no menu em baixo - botton) tem as mesmas
funções que na tela anterior (comentadas logo atrás...) e que agora você dispõe de dois
novos comandos: tecla 'N' para definir um novo tipo de sistema, e a 'M' para montar a
partição.
Mas antes vamos fazer algumas pequenas considerações e indicações, caso você
pretenda usar seu FreeBSD como servidor. Quando você usa a opção Auto Defaults For
All! com a tecla 'A' o Sysinstall calcula o espaço em disco para o FreeBSD junto à
quantidade total de memória para o melhor particionamento possível do disco.
Normalmente esse cálculo é muito bem feito e na maioria das vezes é cabível aceitar o
conselho do sistema em relação ao tamanho das partições. Contudo, em algumas
situações você, como administrador do sistema deve relevar vários fatores.
Esse tipo de análise é válida para qualquer ambiente Unix, mas usuários de FreeBSD
pelo seu bom-senso e experiência em ambientes unix costumam ser mais cuidadosos com
a preparação do servidor que outros administradores de Unix. Apesar da eficiência
conhecida do FreeBSD em trabalhar com um número elevado de dados sem problemas de
perda de desempenho, o particionamento racionalizado de um servidor resulta também
em segurança, visto que possíveis problemas físicos ou lógicos em uma das partições não
afetam as outras, podendo inclusive, em casos extremos ser re-instalada uma partição
(por exemplo, /usr) sem nem tocar em outras (/usr/home e /usr/local por exemplo, caso
tenham sido particionadas distintamente), evitando assim problemas com perca de dados.
Claro que esses exemplos são em casos extremos. Raramente um sistema de arquivos
BSD reporta problemas. Nem diminui seu desempenho. Agoura você já é um expert em
partições FreeBSD... Boa Sorte :)
- X Exit
Volta pra tela anterior.
- All
Instala todas as fontes, todos os binários e todo o Sistema X Window e disponibiliza a
chance de escolher os gerenciadores de janelas e interfaces com o usuário, além de
disponibilizar que todos sejam instalados. É a opção indicada para se instalar tudo!
- Reset
Reseta tudo que você já tenha escolhido, ou seja, não marca nada!
- 4 Developer
Instala todos os sources (fontes), todos os binários e toda a documentação, e não
instala os jogos. É o ideal para usuários que queiram utilizar o FreeBSD como base de
desenvolvimento e programação. Instala tudo que for pra programação e desenvolvimento.
- 5 X-Developer
Instala o mesmo que a opção 'Developer' acrescido do sistema X Windows todo.
Indicado para pessoas que desejam desenvolver em ambiente gráfico também. Instala gtk,
qt, tcl, glade, além do X Windows completo, servidor e fontes.
- 6 Kern-Developer
Instala todos os binários e documentação e as Fontes do Kernel. Opção ideal para
desenvolvedores de soluções com o FreeBSD onde exista a necessidade de implementar
novas rotinas para o Kernel do sistema. Ou simplesmente recompilar o sistema.
Reconendado também para contribuidores diretos do Core-Team.
- 7 X-Kern-Developer
Instala o mesmo que o Kern-Developer acrescido do sistema X Windows todo. Caso
algumas alterações que você venha a implementar no Kernel utilize chamadas da/para a
interface gráfica. Ou simplesmente queira ter o servidor gráfico instalado também.
Utilizado em circunstâncias como desenvolvimento de jogos como o BRain, onde
chamadas no Kernel venham a ser implementadas.
- 8 User
É a opção do sistema para a maioria dos usuários, composta apenas de todos os
binários e toda a documentação. Ideal pros usuários que pretendem utilizar muito o
FreeBSD mas não pretendem desenvolver em cima dele.
- 9 X-User
Instala o mesmo que a opção User, porém acrescidos de todo o sistema X Windows. É a
opção ideal para uma Workstation Unix, fazendo do FreeBSD um sistema de interfaces
gráficas agradáveis e fáceis de se utilizar. Conta com inúmeros gerenciadores de janelas,
todos os mais relevantes desenvolvidos pro servidor X.
- A Minimal
Instala a menor configuração possível para a execução do FreeBSD. É típica de
usuários que preferem instalar aplicações ou módulos do sistema operacional
posteriormente, à medida do necessário, racionalizando assim completamente o espaço
em disco utilizado pelo sistema.
- B Custom
Permite que você mesmo edite a sua distribuição. Pro Alternativo e Anti Social que não
se encaixa em nenhuma das descrições acima, essa é a opção ideal, visto que permite que
você instale apenas o que você selecionar, apenas os conjuntos do sistema que você
deseja (por exemplo, você não quer instalar a Compat 2.2, mas quer as bibliotecas de
criptografia, etc...), os aplicativos que você ache necessários, enfim, tudo escolhido a dedo.
É a mais demorada, visto que são muitas aplicações do sistema e de programas a serem
escolhidas.
Bom, agora você sabe o que cada distribuição instala, e com certeza já sabe qual delas
se encaixa melhor com suas necessidades. Claro que caso você ache que nenhuma delas
é perfeita ao que você precisa, você vai optar por editar por si próprio a sua instalação.
Nesse caso, se isso se tornar uma rotina, é indicado que você crie um arquivo .cfg como
já comentado acima, para poupar seu tempo na seleção dos packages.
No nosso documento vamos escolher a opção 'All' (figura 8) porque estamos instalando
um servidor para Estudos, então sabemos que logo necessitaremos dos outros aplicativos.
Também porque o que não for necessário pode ser excluído posteriormente, com a
utilização das ferramentas pkg_info e pkg_delete, que serão explicadas no Capítulo 3
dessa documentação.
Depois mais uma tela pergunta se você deseja instalar a Coleção de Ports (figura 10) do
FreeBSD. Diz que é uma importante e valiosa coleção que custará apenas 90 Megas de
espaço em Disco para essas mais de 4000 ports. Claro que esses 90 Megas incluem
apenas o início da instalação das Ports. Muito mais espaço será preciso ao instalar e
compilar cada uma delas, e se você é um dos sortudos que tem toda a coleção de CDs do
FreeBSD, as ports já estão todas lá, não será necessário o download das TarBalls.
Bem, mas antes vamos explicar o que são as ports. Ports são programas Unix (e até
Linux) que foram 'Portados' para o FreeBSD, ou seja, foram rescritos e otimizados para
funcionar perfeitamente bem no FreeBSD. Os ports são a maior coleção de aplicativos do
FreeBSD. A instalação dessa 'Ports Collection' vai funcionar da seguinte forma: Serão
instalados vários (inúmeros mesmo) diretórios com vários assuntos diferentes relacionados
aos aplicativos portados, todos a partir do caminho '/usr/ports/' aos quais você poderá
começar a instalação deles. A instalação segue da seguinte forma: você entra no diretório
do assunto e do aplicativo portado que deseja instalar, digita 'make install', então o sistema
se loga no ftp correspondente e baixa a tarball do aplicativo portado, e depois o instala
automaticamente (você não faz nada...:). Sem dúvidas é um processo diferente, e necessita
que você esteja conectado na Internet para isso. Mas como o FreeBSD é um sistema
Servidor de Rede (Internet) cremos então que isso não seja um impecílio. O fator mais
relevante disso é em relação a economia de espaço, já que você apenas baixa os arquivos
que realmente irá necessitar, evitando que eles sejam adicionados na instalação, e permite
que, se você tiver os CDs com os 'Ports Collection', isso se torne ainda mais rápido. Além de
fazer o download da TarBall com o código fonte do aplicativo escolhido e compilar/instalar
o mesmo, o ports ainda trata de verificar a confiabilidade do aplicativo, fazendo a checagem
do Checksum, instalando os Patches quando necessário e inclusive cuidando do
download/compilação/instalação das dependências do aplicativo. O lixo criado pela
compilação e seu fonte descompactado podem ser imediatamente eliminados com o
comando 'make clean' logo depois que a instalação estiver completa. Os arquivos baixados
pelo 'ports' ficam armazenados em '/usr/ports/distfiles/'.
Por tantas vantagens nós optamos (e claro, recomendamos que você faça o mesmo) por
instalar a 'Ports Collection', então escolha o [YES] com louvor (hehehe). Quanto mais
ports disponíveis, melhor, sempre... hoje o FreeBSD conta com 5.103 ports disponíveis, e
essa coleça cresce a cada dia. ];-D
Se você já escolheu que deseja fazer a instalação a partir do CDROM (ou sua escolha)
na opção 'Options' então essa opção já está definida, senão é esse o momento de escolher
de onde você vai instalar tudo, já que até agora você só usou os discos de Boot.
Vou fazer uma consideração que eu jugo importante, sobre a instalação via FTP. É um
dos meios mais recomendados de se instalar o FreeBSD remotamente. É a forma como a
Yahoo instalou o sistema pela primeira vez, e é a forma mais usada para a instalação de
usuários que testam e ajudam no desenvolvimento da série -CURRENT do FreeBSD, já
que apenas os snapshots podem ser encontrados Online, nunca em CDs, imagens ISO ou
outra mídia.
O sysinstall recomenda vários mirrors, em todo o planeta para a instalação via FTP,
inclusive vários no Brasil, situados na Federal do Rio, Universidade de Campinas, Federal
de São Carlos, etc... e permite também que você selecione um endereço manual, caso
deseje instalar via FTP na sua Intranet, por exemplo.
É aqui que finalmente você põe seu sistema para instalar. Usualmente se usa essa
opção para atualizar o sistema com algo que você não tenha instalado também, voltando
a esse menu, dentro do 'sysinstall'.
Finalmente, agora é só sentar e esperar... e ficar atento para um eventual SIM durante
a Instalação. Depois você verá a temida mensagem de ‘Última Chance!’ (figura 12) do
sistema, dizendo que agora seriam feitas todas as modificações nas partições e pra você
somente prosseguir se tivesse certeza. Go On!
Bem, eis que terminou a Instalação do FreeBSD e você cai de volta na tela do
'sysinstall' quando é feita uma pergunta de você deseja rever alguma configuração de seu
sistema. Essa talvez seja a primeira vez que você se vê obrigado a entrar no Configure.
1.5.1. Distributions;
Essa opção permite que você reinstale ou adicione alguma configuração de conjuntos
de distribuições. Já é uma tela conhecida do usuário à essa altura. As explicações para a
distribuição na hora da instalação se aplicam perfeitamente nesse momento. É útil em
casos onde você tenha instalado um sistema enxuto, mas se vê diante da necessidade de
recompilar o sistema. Então a opção de instalação dos fontes necessários (sources) pode
ser utilizada mesmo com o sistema já instalado.
1.5.2. Packages;
Eis uma das opções fundamentais desse menu. O Packages permite que você instale
via 'sysinstall' todos os pacotes pré-compilados para o FreeBSD contidos no CD, tais
como o Apache, WuFtpd, BitchX, gtk napster, qpopper, qmail, entre outros. Essa função
poderia ser feita igualmente com o 'pkg_add' via /cdrom, mas o 'sysinstall' a efetua
automaticamente. Muito importante essa opção, lembre-se dela futuramente.
1.5.4. Label;
Outro item importante, e que também já foi visto. Permite que você redefina agora os
Títulos e partições de sistema (como Swap, /usr...) do seu sistema. Agoura porém é
preciso muito mais atenção, uma vez que seu sistema já está instalado, e mexer nas
partições dele pode por muita coisa a perder. Backup é vida! Poser essa frase, mas se
aplica!
1.5.5. FDisk;
Volta à ferramenta de particionamento do FreeBSD. Assim como o item anterior,
trabalhar com essa ferramenta com o sistema já instalado necessita muita atenção para
não correr riscos de perder informações. Depois de sair do FDisk do FreeBSD, mesmo que
alteração alguma tenha sido efetuada, ele pergunta novamente se você deseja instalar o
'BootMgr' na MBR. Isso é perfeito para restaurar o BootMgr caso seu setor primário de
inicialização tenha sido apagado, ou esteja com problemas.
1.5.7. Console;
Essa opção tem a função de permitir ao usuário que ele customize o console do
sistema de acordo com suas necessidades e gostos. Veremos as sub opções desse menu:
- 1. Font: Permite que você escolha a fonte do console entre uma variedade grande de
fontes disponíveis.
- 3. Repeat: Permite que você configure a taxa de tempo para repetição de caracteres
quando você mantém a tecla pressionada. Existem as alternativas para Slow, Normal,
Fast e Default, na ordem, Lenta, Normal, Rápida e Padrão, onde padrão utiliza o timeout
de repetição que o seu teclado define sozinho.
- 4. Saver: Permite que você escolha entre algumas proteções de tela padrão do console.
Eu pessoalmente gosto da segunda proteção, que é um capetinha em modo texto (ascii)
rodando de um lado pra outro. Faz o servidor ficar bonitinho à vistas das pessoas; O
chucky (capetinha) gráfico também é uma boa opção, mas menos singela... A última
opção define o timeout, em segundos, de quando o Saver vai ser acionado.
- 5. ScreenMap: É recomendado não alterar essa opção a não ser que você more em
algum canto Alternativo da Europa. Brincadeira, ele altera o mapeamento distinto em
países ao redor do mundo, não é o caso de ninguém perto de onde essa documentação vai
ser lida.
1.5.9. Media;
Lembra-se da opção de 'Media' da instalação? É a mesma coisa, permite que você
escolha a mídia de onde você vai instalar/atualizar seus novos Aplicativos da pós-
configuração.
1.5.10. Mouse;
O Sistema informa aqui que você pode Copiar e Colar textos no Console, entre outras
opções, utilizando o 'Mouse Daemon' do FreeBSD para gerenciar seu Mouse. Depois que
você configurou esse Daemon, você pode indicar o caminho '/dev/sysmouse' como sendo
sua unidade de Mouse e 'MouseSys' ou 'MouseSystem' como protocolo do Mouse ao
utilizar o XFree Server. Vejamos então nossas opções:
- Port: Define em que porta (device) está instalado o seu mouse. Normalmente esse
device é o 'sio0', ou seja, a COM1.
- Enable: Liga e testa o Mouse Daemon do FreeBSD. Nessa opção você vai ser
perguntado se seu mouse está funcionando ou não. Caso esteja, responda [YES] e a
configuração é Salva. Senão, digite [NO] e redefina o protocolo (Type) e a Porta (Port) do
Mouse até funcionar. Volte nessa opção para testar.
- Disable: Define que você não vai usar o Daemon SysMouse como device para o seu
mouse, independente deste estar configurado ou não.
1.5.11. Network;
Essa opção gerencia os vários aspectos de configuração da rede, incluindo as interfaces,
clientes, serviços, protocolos e outros. Pode ser considerado o item mais importante dessa
pós-configuração pelo '/stand/sysinstall'. Vejamos agora os itens um por um:
1.5.11.1. Interfaces;
Configura as interfaces de rede do FreeBSD que estão disponíveis no kernel e que
foram identificadas como instaladas pelo Sistema. Normalmente aqui você pode
configurar sua placa de rede, sua conexão PPP, Slip e outras mais usuais. Pode passar
dados às interfaces, como endereço IP, endereço de BroaCast, máscara de rede, gateway
padrão, servidor de nomes, endereçamento via DHCP ou não. Todas opções que serão
preenchidas pelo sysinstall dentro do /etc/rc.conf que contém dados que serão passados
ao kernel e aos daemons e controladoras de interfaces sempre que o precisar dessas
informações (usualmente no momento do boot apenas).
1.5.11.2. NFS Client;
Configura o seu FreeBSD como cliente NFS, caso você for utilizar uma rede NFS para
bootar seu sistema, por exemplo, ou vá montar remotamente alguma partição NFS no seu
sistema local.
1.5.11.4. AMD;
É o Serviço de Montagem Automática de Devices. Ótimo se você tem discos e/ou
partições Linux e/ou Fat e deseja que elas sejam montadas na inicialização, além de
outras utilizações inusitadas.
1.5.11.7. Gateway;
Habilita seu FreeBSD como roteador de pacotes entre as interfaces da rede. É essencial
se você for utilizar seu Free como servidor de Intranet, em especial se ele for servir
Internet à outros clientes Mascarando IPs Falsos, via tabela de tradução de endereços
(técnica NAT).
1.5.11.8. NPDate;
Permite que você se conecte à uma série de servidores que atualizam sua máquina de
acordo com um relógio Atômico, mantendo a hora do seu Servidor sempre atual. Manter as
datas e hora no seu servidor atualizada é ponto crucial para a precisão dos logs gerados
em seu sistema, além de tarefas agendadas. Então automatizar a atualização da sincronia
desses dados é relevante.
1.5.11.9. Router;
Permite que você escolha o Daemon que vai fazer o roteamento na sua rede.
Normalmente, esse Daemon é o Routed, e é o mais indicado também na maioria das vezes.
1.5.11.10. RWhod;
Permite rodar o Daemon do Remote Who no seu FreeBSD. Perigoso, aconselhamos que
somente seja feito se não houver outra alternativa, mas sempre há.
1.5.11.11. AnonFTP;
Permite configurar seu Servidor para aceitar FTP Anônimo. Essa é uma grande
ferramenta pra comunicação atualmente. A Transferência de Arquivos por FTP é bem
mais rápida que HTTP, e a opção de Anônimo permite que qualquer pessoa, mesmo que
não seja usuário de seu servidor, possa transferir os dados que você disponibilizar para o
login anônimo.
1.5.11.12. PCNFSD;
Servidor de Autenticação para Clientes com PC-NFS. Você vai usar muito esse serviço
em uma rede local específica.
1.5.13. Startup;
Aqui você poderá ajustar determinados serviços para iniciarem automaticamente no
momento do Boot do FreeBSD. É importante que você tome cuidado para não inicializar
serviços que não usará ou serviços que possam colocar a segurança de seu servidor em
risco. Serviços que você não use sobrecarregam a memória e processador sem necessidade.
Agoura vamos descrever rapidamente cada um dos principais serviços que podem ser
inicializados no momento do Boot do FreeBSD.
- PCCARD MEM: Se essa opção estiver ligada, inicia junto ao boot um gerenciador de
endereços de Memória para os Cartões PCMCIA.
- NIS Client: Prepara o sistema para ser um cliente NIS. NIS é uma estrutura muito
usada em tráfegos pesados de rede e requer autenticação do usuário no sistema para
realizar qualquer trabalho na rede.
- NIS Domain: Ajusta o 'Domain Name' da NIS, caso este esteja sendo usado.
- NIS Server: Se você for usar seu FreeBSD como Servidor NIS, sendo assim o maior
ponto de referência da Rede para toda e qualquer ação dos usuários, então é aqui que
você inicia o Serviço.
- Accounting: Caso seu servidor for rodar processos de contagem, é aqui que você o
inicia.
- lpd: Caso você tenha uma impressora ligada ao seu sistema, aqui você inicia o
Daemon para gerenciamento de impressoras.
- Linux: Essa é a opção para ajustar a compatibilidade com binários de Linux. Caso
você queira que seu FreeBSD aceite binários escritos para o Linux, então você deve
carregar esse serviço no boot do sistema.
- SCO: Esse outro serviço permite que você execute também Binários IBCS2 utilizados
em SCO Unix.
Essas são as ferramentas que você dispõe para iniciar esses serviços automaticamente,
mas pode-se implementar outros meios de se fazer isso. O uso de Shell Scripts é uma
importante arma no gerenciamento de um sistema.
1.5.14. Option;
Permite que você reajuste ou modifique os mesmos itens da opção 'Option' da
Instalação, o qual foi amplamente comentado na parte de instalação do nosso documento.
1.5.15. XFree86;
Aqui você é auxiliado na configuração do seu Servidor Gráfico XFree. O XFree merece
capítulos e mais capítulos à parte para ser explicado, portanto vamos apenas ajudar na
configuração dele. Mesmo porque o resto você aprende na prática.
- XF86Config: É Um Shell Script para você configurar seu Servidor XFree86 em módulo
Texto, ou seja, no Console. É o mais utilizado deles e o que mais merece atenção.
- XF98Setup: O mesmo que o XF86Setup, mas pra micros mais novos, e chipset de
placas de video distintos.
1.5.16. Desktop;
Depois que seu Servidor XFree já estiver devidamente configurado com seu hardware,
você vai precisar de algum gerenciador de janela. Normalmente por default um
Gerenciador já vem instalado, mas você tem a opção de escolher outro, ou outros,
lembrando que o XFree permite que você utilize mais de um gerenciador gráfico ao mesmo
tempo. Não é kitsch? Vamos ver as opções que temos.
- KDE: 'The K Desktop Enviroment' é um gerenciador Desktop bastante completo e
bem popular que lembra o Windows, e isso as vezes faz com que alguns vários usuários
mais preconceituosos se sintam irritados e não a vontade. Além de ser um gerenciador
Pesado. Mas se sua máquina tiver alguma Memória Ram Disponível, é uma boa opção.
- Gnome + Enlightenment: Combinação perfeita na minha opinião, mas não pode ser
uma opção à se considerar se for utilizar o sistema como servidor, já que sobrecarrega
demais toda a máquina. O Enlightenment por si só já é um gerenciador gráfico pesadinho,
em conjunto com o Gnome a coisa fica ainda mais agravante, e em um servidor não se
pode brincar de desperdiçar recursos. Em compensação como DeskTop, Workstation, a
dobradinha G+E garante um módulo gráfico bonito, fácil de utilizar e muito ágil.
Compensa conhecer se já não forem velhos conhecidos do Linux ou outros Unix.
- WindowMaker: Um dos gerenciadores XFree que mais tem fãs e usuários. É leve, tem
uma aparência bonita, Desktop customizável... Enfim, Perfeito para máquinas que não
tenham recursos sobrando mas nem por isso deixam a desejar.
Como nossa documentação é escrita à partir de um servidor, nós não indicamos que se
utilize muito de Interface Gráfica, para poupar recursos de Memória e Processamento. É
interessantíssimo evitar sempre que possível que o XFree86 esteja sendo executado,
mesmo porque, por ser um 'Servidor' Gráfico, é possível que seja acessado remotamente.
Mas sem pensar na segurança, nos mantendo apenas nos recursos, é desaconselhável
usar o X.
Claro que não podemos deixar de recomendar que você instale uma interface mais
completa e mais bonita, quando tiver hardware sobrando, só pra ter o gostinho de ver
como o Desktop do FreeBSD pode ser a uma alternativa mais bonita e mais fácil até que
sistemas operacionais gráficos, como Window$ ou OS-9. E já que citamos o OS 9,
comparemos então com a interface aqua existente no OS X da Apple. Já que eles se
inspiraram no FreeBSD e BSD 4.4 pra fazer seu kernel unix (o Darwin) se inspiraram
também na interface. Toda a transparência é conhecida de usuários do Enlightenment e
as espeficiações swing da interface Aqua é analogia direta do gtk.
A Camada seguinte na nossa máquina de níveis exemplo, é a Shell. Shell é uma porta
de entrada para a comunicação do usuário com o sistema operacional, com o kernel, com
o computador. A Shell é composta basicamente de uma capsula (shell) que liga você
(usuário) ao sistema operacional. É provida de interpretadores de comandos, que tem a
função de entender ordens digitadas no ambiente (shell) como comandos, procurar nos
caminhos pré-definidos (path) aqueles comandos (em forma de binários ou ambiente) e
executa-los tratando da forma como for necessária, e ao final da ação, retornando uma
resposta de volta ao usuário.
Então, quando você digita 'ls' por exemplo, a shell (interpretador de comando em
questão) procura por um código de máquina (binário) que corresponda à ordem dada pelo
usuário, e então encontra o ls, executa-o e retorna resposta pro usuário. Esse 'executar'
em questão consiste em interpretar os códigos daquele programa, envia-lo ao kernel, que
analisa o que a shell esta pedindo e retorna a resposta, então a resposta é retransmitida
ao usuário. Então quando um ls retorna todos os arquivos e diretórios de um outro
diretório, o que realmente esta acontecendo é: o interpretador de comando (shell) esta
enviando ao kernel uma ordem dizendo que o usuário quer saber o conteúdo do trecho do
disco em questão. Então o kernel varre esse trecho do disco, descobre todos os arquivos e
outros diretórios contidos, nome dado a cada um desses arquivos, tamanho que eles
estão ocupando em disco (inodes) e retorna pra shell.
Normalmente quando essa resposta é retornada à shell ela ainda é interpretada antes
de ser repassada ao usuário, mostrando o nome do arquivo/diretório, espaço em disco
que está sendo utilizado (inodes interpretados em bytes) e outras informações distintas.
Esse tipo de comunicação entre hardware-kernel via shell acontece sempre, mesmo
quando você não está enviando comando algum ao sistema. Em alguns ambientes, você
pode inserir ainda uma camada gráfica entre a shell e o usuário, chamada de GUI, que é a
interface gráfica. Nesse caso essa interface, em forma de janelas, normalmente, interpreta
a resposta do kernel e retorna um ambiente gráfico, com icones de pastas onde são
diretórios, icones específicos para cada tipo de arquivo, enfim, tudo de glamuroso e
agradável que o ambiente gráfico proporciona. Contudo é uma camada a mais na
máquina de níveis até o kernel, o que resulta em perda de desempenho.
A consequência disso é um kernel que, por mais enxuto que seja, vai conter suporte a
inúmeros dispositivos que simplesmente não existe no seu computador. E mesmo não
existindo, o kernel vai ter a habilidade de controla-los. E nesse casos, essa habilidade é
sinônimo de recursos (memória/processamento) sendo utilizados sem necessidade. Então,
se a possibilidade de controlar dispositivos que nós não temos utiliza recursos, porque
simplesmente não retiramos essas habilidades do kernel?
Em sistemas proprietários você não pode nem abrir o kernel, tão pouco altera-lo
customiza-lo, como sistemas da Novell, da Microsoft (windows), e outros Unix
proprietários. O resultado dessa incapacidade é um kernel grande, cheio de suporte a
dispositivos que nós não temos, e, infelizmente muitas vezes a incapacidade de controlar
algum dispositivo que nós temos. É a ironia em forma de sistema, nós termos um kernel
que trate dispositivos estranhos mas não trate os que nós temos. Nesse caso é necessário
uma camada a mais, ou seja, um nível a mais na nossa máquina de níveis entre o kernel
e o hardware, que são os chamados 'drivers'. Resultado é um kernel grande, cheio de
suporte a dispositivos inexistentes no nosso computador, e acrescido ainda de mais uma
camada, distânciando ainda mais o kernel do hardware, e consequentemente o hardware
do usuário. Com isso você imagina os recursos que são utilizados, e como o desempenho
da nossa maquina vai descrescer relevantemente.
Enfim, sabendo utilizar o kernel de um sistema da melhor forma possível, você com
certeza terá rendimentos mais proveitosos. Porém essa vantagem toda pode se virar contra
o usuário e se tornar uma longa dor de cabeça, se por ventura, você sobrecarregar seu
kernel, ou implementar suportes incorretos a determinado dispositivo.
Se você está migrando de um outro sistema Unix, ou mesmo de um Linux, por exemplo
já saber que otimizar e recompilar um kernel é tarefa usual nesse maravilhoso mundo do
código fonte aberto. Agora, nós vamos ao longo desse capítulo, ensinar a você como
compilar, da forma correta, o kernel para o seu FreeBSD.
Sabemos muito bem os maiores problemas de sistemas operacionais que não nos
permite customizar nosso kernel para, apenas o que nós precisamos. É um pesadelo ter
um sistema que suporta diversos periféricos e placas que saem completamente de nossa
realidade ou necessidade.
Tendo um kernel que suporte exatamente todo o nosso sistema e as funções que nós
queremos utilizar nele, economizará relevantemente o consumo de Recursos de nosso
sistema... E recursos obviamente é algo que quanto mais pudermos trabalhar de forma
racional, melhor maneiras teremos de proporcionar a performance máxima de nossa
máquina.
No FreeBSD, quando inciamos nosso sistema pela primeira vez, utilizamos um kernel
padrão, chamado de GENERIC. Esse kernel possui suporte a grande maioria dos
dispositivos e controladores existentes. É sem dúvida o bastante para utilizar seu sistema.
Contudo, esse kernel GENERIC, apesar de compacto contém suporte a tipos distindos de
dispositivos, e não contém algum suporte a tarefas importantes, as quais nós veremos
futuramente.
A configuração do novo kernel deve ser baseada nas entradas de um segundo arquivo,
o LINT. O LINT é um arquivo que contém todos os dispositivos suportados pelo FreeBSD,
e não pode jamais ser seguido a risca para configuração de um novo Kernel. O ideal é você
fazer uma cópia do seu kernel genérico e a partir dele, iniciar a configuração de seu
kernel, sempre consultando o LINT para saber como inserir suporte à dispositivos que
você necessite. Quanto mais você conhecer o LINT mais poderá otimizar seu sistema.
Inicialmente seu sistema deve ter reconhecido todos os dispositivos básicos da sua
máquina, utilizando-se pra isso o kernel GENERIC. Comumente alguns dispositivos não
são reconhecidos da forma correta. Isso ocorre em especial com MODEMs e Placas de
Rede ou de Som, porque são definidas portas e IRQs diferentes das que ele está
trabalhando.
O que acontece então? Todas as entradas para que o FreeBSD possa controlar esse
dispositivos básicos estão presentes no arquivo de configuração GENERIC do kernel, mas
pode acontecer algum conflito ou não satisfação de recursos. Por exemplo, o kernel
procura por aquele recurso em determinada Interrupção (IRQ) e determinada DMA... e seu
dispositivo se encontra em outra IRQ e DMA. Esses são os fatos mais usuais, assim como
o recurso procurando em device diferente da qual seu hardware está instalado. Isso quase
sempre ocorre com o MODEM, uma vez que o FreeBSD procura por ele na cuaa1 (sio1 -
que é a COM2), e várias vezes ele está na COM4 (cuaa3, sio3), ou outras delas. As vezes
acontece também com placas de som, ou placas multi-seriais.
Como resolver esses e outros problemas você verá a seguir, assim como implementar
propriedades que o kernel usual não ostenta, como o uso de quotas por exemplo.
Mais uma vez, antes de iniciarmos a compilar o nosso kernel, eu relembro vocês
(desculpe se esta massante, mas é importante você assimilar isso), que é ótimo conhecer
o LINT antes de inciar a configuração de seu novo kernel. Por isso de uma boa olhada e
leia antentamente o LINT. Em Inglês de fácil entendimento. Um amigo meu está
trabalhando na tradução do LINT do FreeBSD 4.3 e eu prometo disponibiliza-lo em um
próximo review desse capítulo. Contudo o LINT muda a cada versão, e queira ou não você
vai precisar ler esse arquivo quando não souber determinado parâmetro ou sintaxe da
entrada do kernel.
A partir do momento que você conhece o hardware do sistema para o qual você
pretende customizar seu kernel, tudo se torna mais fácil. Vamos então agoura guia-lo
passo a passo durante a criação de seu novo kernel. Se você estiver trabalhando em
plataforma Alpha, considere o caminho: /usr/src/sys/alpha/conf ao longo da
documentação.
# cd /usr/src/sys/i386/conf
- Agora faça uma cópia do arquivo de configuração do kernel genérico como o arquivo de
configuração de seu novo kernel. Lembrando das dicas básicas, que o kernel deve estar
em letras maiúsculas e com o nome da máquina.
# cp GENERIC EEVIACBSD
Claro que para esse exemplo eu considerei que a máquina em questão se chamasse
EeviacBSD, que é a minha estação.
- O terceiro passo é o passo prático em si. Esse passo é onde nós editaremos o nosso
kernel. Utilize o editor que você mais gosta para edita-lo. No nosso caso, sempre
aconselhamos o editor padrão, o ‘ee’.
# ee EEVIACBSD
Agora sim, eis o arquivo de configuração do kernel atual na nossa frente. É nesse
arquivo que iremos excluir os suportes que não precisamos, e adicionar os que venhamos a
necessitar. No nosso caso, tivemos alguns probleminhas, entre os quais incluía a nossa
placa de rede. Para tanto, concluímos então que a melhor maneira de configurar o nosso
kernel, era começando pela exclusão dos suportes os quais nós não necessitávamos.
Pra isso, o que fizemos e aconselhamos que você faça também, é ler todo o seu kernel.
Como nós não utilizamos disco rígidos SCSI (em caso de compilação para servidores
possívelmente você vai estar utilizando SCSI, então atenção em qual controladora você vai
excluir), retiramos todo o suporte a controladoras desse tipo. Retiramos também suporte a
alguns protocolos de placas de rede que sabíamos não ser a que nós utilizaríamos.
Sabíamos que a nossa era uma NE2000 compatível e uma 3Com.
Depois de uma primeira enxugada imediata, quando você bate os olhos e sabe que não
precisa daquilo, chegou a hora de retirar suporte a outros dispositivos que também não
estavam sendo utilizados.
Portanto use o comando dmesg, depois disso pressione a tecla Scroll Lock para travar
sua tela, e role-a com Page Up e Page Down para ir anotando o que o seu kernel não
encontrou. Depois de anotado os ‘not found’, você já tem em mãos a grande maioria dos
dispositivos que seu kernel suporta mas que não estão sendo utilizados. Ou seja, estão
sobrecarregando seus recursos.
Agora com certeza você já tem uma boa lista de itens a serem retirados do seu kernel.
Agora que você já deu uma drenada básica no seu kernel, é hora de conhecer o resto
dos dispositivos básicos que ele suporta. Segue então o seu kernel genérico comentado
linha a linha. Esses comentários foram enviados em uma lista de discussão, e foram
devidamente analisados e modificados antes de entrar na documentação de FreeBSD
utilizado por nós.
machine ``i386''
Bom, uma vez que o FreeBSD roda sob a arquitetura intel ou compativel, associamos a
esta palavra chave esta o valor "i386". Caso você seja um dos privilegiados que esta
trabalhando com o FreeBSD em plataforma alpha basta modificar essa linha pra avisar o
kernel, mas seu GENERIC já vai ter se encarregado de ajustar isso pra 'alpha'.
cpu ``cpu_type''
Inclui no kernel o suporte para cada tipo de CPU suportada pelo FreeBSD.
o I386_CPU
o I486_CPU
o I586_CPU (Pentium)
o I686_CPU (Pentium Pro)
O kernel generico possui suporte a todos os tipos de CPU, de modo que ao recompilar
seu kernel e recomendado que voce inclua no seu kernel, suporte apenas para a CPU que
voce possui.
ident EEVIACBSD
Esta e a identificacao do seu kernel. Uma boa escolha e utilizar o hostname como
nome do kernel, isso facilita quando se possui varios hosts, cada um com um kernel
diferente, em uma mesma rede.
De uma forma geral esta variavel deve ter o valor definido de acordo com o numero de
usuarios simultaneos que voce espera ter em seu sistema, pois o numero maximo de
processos simultaneos que seu sistema podera executar, sera dado pela expressao: 20 +
16 * <maxusers>
OBS: O valor definido como maxusers nao limita o numero de usuarios que podem
logar simultaneamente no servidor, e sim o número máximo.
Agora sim, você vai acompanhar cada iten suportado pelo seu sistema. Esse debug do
kernel GENERIC deve ser creditado à FreeBSD Primeiros Passos, mantida por Edson Brandi,
provavelmente a publicação na lista de discussões também tem crédito a ele.
options MATH_EMULATE
Informa ao kernel para simular um co-processador matematico caso seu computador
nao possua um. Voce so vai precisar desta linha se seu PC for um 386 ou um 486 SX.
options ``COMPAT_43''
Inclui ao seu kernel, compatibilidade com o 4.3 BSD.
options BOUNCE_BUFFERS
Dispositivos ISA ou EISA , operando no modo de compatibilidade ISA, so podem
acessar sua memoria DMA em sistemas com menos de 16 MB de RAM. Esta opcao ira
permitir que os dispositivos que usam DMA funcionem em sistemas com mais de 16 MB
de memoria.
options UCONSOLE
Esta opcao ira permitir a seus usuarios definir um console para o qual deverao ser
enviadas todas as mensagens enviadas a voce (talk, write, etc).
options SYSVSHM
Esta linha prove suporte ao sistema de memoria compartilhada do System V. Se voce
pretende emular programas Linux ou jogar games como o DOOM ou QUAKE nao deixe de
incluir esta linha ao seu kernel.
options SYSVSEM
Esta linha prove suporte ao sistema de semafaros do System V.
options SYSVMSG
Esta linha prove suporte ao sistema de mensagens do System V.
options FFS
Esta linha inclui no kernel o suporte basico ao sistema de arquivos de um HD. Linha
obrigatoria para que possui um HD.
options NFS
Esta linha inclui no kernel suporte ao sistema de arquivos NFS. Se voce nao planeja
usar seu sistema como servidor ou cliente NFS voce pode remover esta linha do seu
kernel.
options MSDOSFS
Esta linha inclui no kernel suporte ao sistema de arquivos do MS-DOS. Se voce nao
planeja montar nehum HD que utilize este sistema de arquivos, voce pode remover esta
linha do seu kernel.
options ``CD9660''
Esta linha inclui no kernel suporte ao sistema de arquivos ISO 9660 para Cd-ROMs.
Voce pode remover esta linha de seu kernel caso voce nao possua um drive de CD-ROM.
CDs de audio nao precisam deste suporte.
options PROCFS
Esta linha inclui no kernel suporte ao sistema de arquivos utilizado pelo sistema para
gravar informacoes sobre os processos em execucao (/procs), linha obrigatoria para a
maioria dos sistemas.
options MFS
Esta linha inclui no kernel o suporte ao sistema de arquivos "Memory-mapped".
Basicamente um disco em memoria RAM usado para armazenar rapidamente arquivos
temporarios.
options QUOTA
Esta linha inclui no seu kernel o suporte ao sistema de quotas dem disco.
options INET
Inclui suporte para Networking (rede).
controller isa0
Esta linha inclui ao kernel suporte a barramentos ISA.
controller pci0
Esta linha inclui ao kernel suporte a barramentos PCI.
controller fdc0
Esta linha inclui no seu kernel suporte a controladora de floppy drives (Discos flexiveis
ou tapes de backup)
controller adc0
Esta linha inclui no seu kernel suporte a controladora IDE primaria. Os dispositivos
wd0 e wd1 sao respectivamente os HDs master e slave. wdc1 e a controladora IDE
secundaria.
device acd0
Esta linha inclui no seu kernel suporte a CD-ROMs IDE. Se voce possui um CD-ROM
IDE certifique-se de incluir a linha "options ATAPI" ao seu kernel.
controller uha0 at isa? port ``IO_UHA0'' bio irq ? drq 5 vector uhaintr
Inclui suporte as controladoras SCSI da UltraStor modelos 14F e 34F.
controller ahc0
Inclui suporte as controladoras SCSI Adaptec modelos 274x/284x/294x.
controller aha0 at isa? port ``IO_AHA0'' bio irq ? drq 5 vector ahaintr
Inclui suporte a controladora SCSI Adaptec modelo 154x.
controller sea0 at isa? bio irq 5 iomem 0xc8000 iosiz 0x2000 vector seaintr
Inclui suporte a controladora SCSI Seagate ST01/02 8 bit.
controller wds0 at isa? port 0x350 bio irq 15 drq 6 vector wdsintr
Inclui suporte a controladora SCSI Western Digital WD7000.
controller ncr0
Inclui suporte as controladoras PCI SCSI modelos NCR 53C810, 53C815, 53C825,
53C860 e 53C875.
options ``SCSI_DELAY=15''
Esta linha informa ao kernel para fazer uma pausa de 15 segundos antes de testar
cada dispositivo SCSI em seu sistema.
controller scbus0
Se voce possui alguma controladora SCSI, esta linha prove um suporte generico aos
dispositivos SCSI. Linha obrigatoria caso voce possua algum dispositivo SCSI.
device sd0
Inclui suporte a HDs SCSI.
device st0
Inclui suporte a tape drives SCSI.
device cd0
Inclui suporte a CD-ROMs SCSI.
options ``PCVT_FREEBSD=210''
Linha obrigatoria quando se utiliza o driver de console vt0
options XSERVER
Linha obrigatoria quando se utiliza o driver de console vt0 e se pretende rodar o
XFree86.
device psm0 at isa? port ``IO_KBD'' conflicts tty irq 12 vector psmintr
Insira esta linha caso voce possua um mouse do tipo PS/2.
device de0
Inclui suporte a placas de rede ethernet baseadas nos chips DC21040, DC21041 e
DC21140 da Digital.
device fxp0
Inclui suporte a placa de rede ethernet Intel EtherExpress Pro/100B.
device vx0
Inclui suporte a placas de rede ethernet 3Com modelos 3C590 e 3C595.
device cx0 at isa? port 0x240 net irq 15 drq 7 vector cxintr
Inclui suporte a placas multiportas Cronyx/Sigma sync/async.
device ed0 at isa? port 0x280 net irq 5 iomem 0xd8000 vector edintr
Inclui suporte a placas de rede ethernet da Western Digital SMC 80xx e 8216; Novell
NE1000 e NE2000; 3Com 3C503; HP PC Lan Plus (HP27247B e HP27252A)
device ie0 at isa? port 0x360 net irq 7 iomem 0xd0000 vector ieintr
Inclui suporte a placas de rede ethernet AT&T StarLAN 10 e EN100; 3Com 3C507;
padrao NI5210.
device ix0 at isa? port 0x300 net irq 10 iomem 0xd0000 iosiz 32768 vector ixintr
Inclui suporte a placa de rede ethernet Intel EtherExpress 16.
device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr
Inclui suporte a placas de rede ethernet Digital EtherWorks 2 e EtherWorks 3 (DEPCA,
DE100, DE101, DE200, DE201, DE202, DE203, DE204, DE205, DE422).
device lnc0 at isa? port 0x300 net irq 10 drq 0 vector lncintr
Inclui suporte a placas de rede ethernet Lance/PCnet (Isolan, Novell NE2100, NE32-
VL).
device ze0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector zeintr
Inclui suporte ao controlador ethernet PCMCIA da IBM/National Semiconductor.
device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr
Inclui suporte ao controlador ethernet 3Com PCMCIA Etherlink III.
pseudo-device loop
Interface de loopback para TCP/IP. Linha obrigatoria.
pseudo-device ether
Linha obrigatoria caso voce possua alguma placa de rede.
pseudo-device sl numero
Inclui suporte ao protocolo SLIP, o numero especificado determina quantas conexoes
SLIP seu server pode manter simultaneamente.
controller snd0
Inclui suporte para uma placa de som generica. Linha obrigatoria caso voce possua
uma placa de som.
device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr
Inclui suporte a placa de som SoundBlaster audio digital.
pseudo-device gzip
Esta linha permite ao FreeBSD executar o rpograma gzip.
pseudo-device log
O log e usado para gravar as mensagens de erro do kernel. Linha obrigatoria
device de0
device fxp0
device tl0
device tx0
device vx0
device xl0
Mais Devices de rede, não se pode modificar a ordem dessas e das próximas entradas,
porque elas devem ser procuradas e reconhecidas em uma ordem certa.
No momento ie0 deve ser procurada antes de ep0, aguarde as atualizaçòes na revisão
1.20 desse arquivo
device ed0 at isa? port 0x280 net irq 10 iomem 0xd8000 vector edintr
device ie0 at isa? port 0x300 net irq 10 iomem 0xd0000 vector ieintr
device ep0 at isa? port 0x300 net irq 10 vector epintr
device ex0 at isa? port? net irq? vector exintr
device fe0 at isa? port 0x300 net irq ? vector feintr
device le0 at isa? port 0x300 net irq 5 iomem 0xd0000 vector le_intr
device lnc0 at isa? port 0x280 net irq 10 drq 0 vector lncintr
device ze0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zeintr
device zp0 at isa? port 0x300 net irq 10 iomem 0xd8000 vector zpintr
device cs0 at isa? port 0x300 net irq ? vector csintr
pseudo-device loop
pseudo-device ether
pseudo-device sl 1
pseudo-device ppp 1
pseudo-device tun 1
pseudo-device pty 16
pseudo-device gzip # Exec gzipped a.out's
options KTRACE #kernel tracing
options SYSVSHM
É o suporte ao sistema de compartilhamento de memória dos Unix System V.
Pronto! Teoricamente agoura você já tem informações mais que suficiente para ajustar
o kernel do seu sistema de acordo com suas necessidades. Agora sim é hora de finalmente
compilar o núcleo do seu sistema. Mas antes você deve considerar não retirar nenhum
suporte que você não esteja certo de não precisar. Isso pode ser fatal no seu sistema, ou
pode ser uma dependência em potencial.
Para compilar agora seu kernel de acordo com as configurações que você acabou de
ajustar, faça o seguinte.
- Configure seu Kernel, digitando config NOME_DO_SEU_KERNEL, no nosso caso:
# config EEVIACBSD
# cd ../../compile/EEVIACBSD.
# make depend
As coisas agora começam a demorar um pouco, variando de acordo com sua máquina.
De qualquer forma, você está começando a compilar o núcleo do seu sistema. Se você está
achando isso interessante mal espere a chegarmos na atualização do fonte todo de nosso
sistema, o make world :-). Bom, voltando ao kernel:
- Depois que as dependências foram satisfeitas, é hora de construir seu novo kernel. O
passo seguinte agora é dar um Make. Digite então:
# make
Mais algum tempo será necessário. Agora o sistema estará construindo o seu novo
kernel, de acordo com as dependências do sistema, ou seja, criando um kernel
exatamente para o sistema. Nesse ponto, se alguma configuração do kernel que você
editou não estiver de acordo com o sistema, você verá algumas mensagens de erro.
# make install
Agora ele vai compilar o seu kernel no seu sistema, como sendo o kernel do próprio, ou
seja, vai instalar o seu kernel.
Desse momento em diante você elegeu o novo kernel como o kernel do FreeBSD. Agora
é só reiniciar seu sistema com um reboot rápido, para então carregar sua máquina com
seu novo kernel.
# fastboot.
Agora você está mais que andando com suas próprias pernas, está andando com as
pernas que você escolheu pra si mesmo. Ou não? Bom, agora que você bootou com seu
novo kernel, é hora de você descobrir se tudo está funcionando bem, e, especialmente, se
por ventura o motivo maior de você recompilar seu kernel (algumas vezes, dispositivos,
como o MODEM) satisfez suas expectativas.
Caso o resultado seja negativo, recompile seu kernel usando os dados certos. É
fundamental conhecer duas coisas no seu dispositivo: DMA e IRQ. Se esses dados não
estiverem dispostos corretamente pro kernel, ele nunca os reconhecerá. Se você errou,
recompile o kernel de novo.
Agora a parte que muitos estão esperando chegar para saber. Se por algum motivo seu
sistema não iniciou com seu novo kernel, então basta digitar kernel.old no momento do
boot. Dessa forma você inicia sua máquina com o núcleo antigo.
Para isso:
# cd /usr/src/sys/i386/conf
# cp GENERIC EEVIACBSD
# ee EEVIACBSD
# config EEVIACBSD
# cd ../../SEU_KERNEL
- Cumpra as dependências.
# make depend
# make
# make install
# fastboot
- Lembre-se, se não bootar com o novo kernel, então inicie seu sistema com o kernel
antigo, digitando kernel.old no momento do boot.
- Tire o resto do dia de folga, vá beber uma pepsi ao som de Pearl Jam com os amigos.
Computador te deprime, os amigos te sorriem :) (how poser...)
Até o momento da edição do novo Kernel, tudo permanece igual, contudo desde o
config pra frente, a rotina se altera.
# cd /usr/src/
# make buildkernel KERNEL=EEVIACBSD (no caso considerando EEVIACBSD como o
nome do Kernel)
# make installkernel KERNEL=EEVIACBSD
Agora sim o segundo comando instala o novo kernel do seu FreeBSD e te deixa a
vontade para reiniciar seu sistema e usar seu novo kernel. Caso haja algum problema as
ações a serem tomadas são as mesmas já explicadas ao longo desse documento.
Como você pode perceber essa maneira é mais simples e mais automatizada.
Atualmente as duas maneiras podem ser feitas para compilar um novo kernel pro seu
sistema, contudo em versões futuras não sabemos quais delas vão ser adotadas nem se
ambas vão continuar a co-existir. No FreeBSD -CURRENT, versão 5.0-20001223
com últivo CVSup (atualizacão completa do sistema, veja capítulo 4) realizado em 28 de
Abril (2001), foram encontrados erros durante a checagem de dependências manualmente
no kernel, contudo a compilação dessa segunda forma ocorreu perfeitamente, o que deixa
claro que a forma com que o sistema checa as dependências nessa segunda maneira são
distintas. Talvez essa seja adotada.
Vamos supor então que seu modem esteja na COM4 do Windows. Essa configuração é
a mais comum dos modems internos no Brasil. Se você tem modem externo, certamente
ele deve estar na COM2, não tendo problemas com isso. No FreeBSD a COM4 é a device
cuaa3 (sio3 para o kernel).
Dessa forma, a configuração inicial que você tem no seu kernel será algo como:
Como você pode visualizar, a sio2 e sio3 estão desligadas (disable). Para que o kernel
enxergue seu modem, no nosso exemplo, onde a COM4 tem o modem instalado, você deve
remover a palavra disable da linha da COM4 (sio3) e configurar a IRQ de acordo com a do
seu modem. Na minha casa, o FreeBSD está assim:
# Serial (COM) ports
device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4
device sio1 at isa? port "IO_COM2" tty irq 5
device sio2 at isa? disable port "IO_COM3" tty irq 5
device sio3 at isa? port "IO_COM4" tty irq 3
Assim que você recompilar seu kernel novamente, seu modem estará respondendo.
Claro, desde que você realmente tenha um modem, certo? Não vá achando que qualquer
modemzinho de 80 reais vai ser reconhecido dessa forma. Modem é Modem. Modens que
compartilham recursos (memória e processamento) com o RAM e CPU principal do
computador não são suportados pelo FreeBSD, porque não são MODEMs. Portanto nada
que se pareça com winmodem é suportado pelo kernel do FreeBSD.
Agora cuidaremos para que o kernel do seu FreeBSD suporte o sistema de controle de
quotas. Esse sistema de controle de Quotas é um atributo muito importante no FreeBSD.
Ele permite que você defina quanto cada usuário pode usar de espaço em disco para suas
atividades.
Bom, basicamente o que você precisa fazer para iserir o suporte ao controle de Quotas
no kernel do seu FreeBSD, é simples, basta inserir uma linha na configuração do seu
Kernel.
A linha em questão é "options QUOTA" e para fazer isso você tem duas maneiras,
óbvias, claras e fáceis. A primeira é editar seu kernel com seu editor de textos preferido, e
a Segunda é adicionar sem editor de texto algum. Vejamos agora.
# cd /usr/src/sys/i386/conf
# ee SEU_KERNEL
Ou então:
Pronto, agoura basta compilar o seu kernel de novo, e seu sistema já estará com
suporte a Quotas. A Configuração de Suporte a Quotas do FreeBSD pode ser encontrada
na documentação apresentada no próximo capítulo.
Antes de reiniciar seu sistema com o novo kernel, porém, edite o arquivo /etc/rc.conf e
substitua a linha ‘check_quotas="NO"’ para ‘check_quotas="YES"’
Mais a frente você encontrará documentos mais detalhados sobre a utilização dessas
ferramentas, mas agoura vamos nos direcionar à implementação do suporte ao kernel para
elas.
options IPFIREWALL
Essa opção define o suporte do kernel ao IP FIREWALL. Essa é uma opção relevante e
fundamental para configuração de qualquer bom firewall. Insira essa opção no seu kernel
sem dúvidas!
options IPFIREWALL_VERBOSE
Permite que a codifição dos pacotes sejam logadas. É a única maneira dos logs serem
efeitvados pelo syslogd. Sem essa opção, mesmo que você queira que seu firewall logue
suas atividades, nada acontecerá.
options IPFIREWALL_FORWARD
Permite suporte a Proxy Transparente. Importantíssimo de acordo com suas
necessidades.
options "IPFIREWALL_VERBOSE_LIMIT=100"
Define o tamanho do limite dos logs a serem "remanjejados" pro syslogd. A
Documentação oficial do FreeBSD faz uma piada dizendo que essa opção é importante em
redes hostis, para evitar que você crie um ataque de "Denial Of Services" com os Logs do
sistema por acaso.
options IPFIREWALL_DEFAULT_TO_ACCEPT
O Padrão da implementação do IPFIREWALL é negar pacotes de qualquer fonte para
qualquer destino. Essa opção faz o contrário, e diz que você vai permitir o repasse desses
pacotes de qualquer fonte para qualquer destino. A idéia dessa opção é fazer uma
implementação contrária, onde quase tudo é permitido, e você vai criar regras de negação
de pacotes manualmente.
Para adicionar esse suporte ao kernel, basta adicionar uma linha no seu kernel:
options DUMMYNET
Bom, para adicionar então essas opções no kernel, edite o arquivo de configuração do
seu kernel e insira os suportes desejados:
# ee /usr/src/sys/i386/conf/SEU_KERNEL
# cd /usr/src/sys/i386/conf/
# cat LINT | grep IPFIREWALL >> SEU_KERNEL
E no caso do DUMMYNET:
# cd /usr/src/sys/i386/conf/
# cat LINT | grep DUMMYNET >> SEU_KERNEL
Pronto! Agoura você já sabe como implementar os suportes necessários aos principais
módulos de firewall do seu FreeBSD. Veja mais sobre Firewall com FreeBSD e sobre o
ipfw nos capítulos seguintes. Adicionar o IPF e o IPSec no seu kernel é exatamente igual
os exemplos com o IPFIREWALL e com DUMMYNET
Claro que a conclusão, partindo do fato do sistema reconhecer outras placas ISA e PCI,
é que o kernel genérico não estava com entradas compatíveis no que dizia respeito a placa
de rede e o micro. Então a solução clara era, recompilar o kernel para ele reconhecer a
placa de rede.
Percebemos então que essa combinação de DMA e IRQ eram, de certa forma, uma das
mais requisitadas do sistema.
A primeira alteração no kernel foi alterar as entradas da DMA e da IRQ da ed0 (device
da placa de rede) para os respectivos valores. Quando bootamos o kernel, novo, o
resultado foi: placa de rede reconhecida. Quatro linhas depois, o boot parou. Comflito da
IRQ 3 com determinado device que não servia pra nada.
A solução foi alterar aquela device. Agora a IRQ 3 não era mais necessária por aquele
problemático artefato.
Nada feito, só reconhecia mesmo na 0x300. Estranho, também achei, mas era o fato.
Percebi então que alguns dos dispositivos que usavam esses mesmos recursos nem
eram necessários ao sistema, foi então que resolvi fazer o que eu dei a dica no sub-
capítulo logo acima. Usando o dmesg eu vi tudo que era ou não necessário, foi tudo então
retirado, e o que sobrou que era necessário e pedia o mesmo recurso, foi delicadamente
atribuído às devidas IRQs e DMAs possivelmente compatiíveis com as que eles requeriam.
Como já havíamos testato isso na placa de rede, e ele realmente queria de toda forma os
recursos citados, fizemos isso com os outros dispositivos então.
E se algo deu errado com seu novo kernel, lembre-se, para bootar usando o kernel
anterior, na prompt do boot do sistema, onde aparece escrito F1 Dos, F2 FreeBSD, (ou
diferente), aperte a tecla de espaço, e depois entre com o kernel.old, apenas digitando
"kernel.old". Em ambiente futuro pode existir a nacessidade de digitar load kernel.old na
tela de contagem de 10 segundos, apertando a barra de espaço. Pronto, agora é só
conferir o que não foi bem editado em seu kernel, arrumar o problema e compilar de novo.
Olá! Esse capítulo da nossa documentação poderia ter o nome de Misc, de Mais
Informações ou qualquer outra coisa que sintetizasse a junção de uma série de
informações breves porém de suma importância. E é justamente isso que nós trataremos
agora, das questões mais comuns relacionadas a configuração do FreeBSD, e que na
maioria das vezes, as soluções são simples e diretas. Aproveite esse que com certeza será
um dos capítulos mais consultados da nossa documentação.
Já foi comentado no Capítulo 1 dessa documentação o que são os ports, mas vamos
relembrar. Ports são aplicativos que foram portados, ou seja reescritos para o sistema
FreeBSD. É uma coleção com milhares de aplicativos de outros Unix (Unices), e
especialmente de Unix-Like do tipo Linux, que foram escritos novamente para
funcionarem perfeitamente, e as vezes até melhor que os originais, em plataforma
FreeBSD. Esses aplicativos são portados por inúmeros programadores ao redor do mundo
que programam para o FreeBSD; A comunidade FreeBSD é ainda mais absolutista que
outras de Unix de fonte aberto... por isso a qualidade dos aplicativos portados é louvável.
Para instalar, basta entrar dentro do diretório do aplicativo que você quer e digitar
make install.
# cd /usr/ports/sub_dir/dir_do_aplic
# make install
A partir desse momento o sistema se loga em algum dos endereços da internet pré
definidos no índice, baixa o código fonte, compila e instala o aplicativo. Conforme
percebe-se, para instalar um aplicativo portado pelo ports, é necessário estar na Internet.
O BASH com certeza é o Interpretador de comandos (Shell) mais usado e mais querido.
Contudo, o bash tem alguns problemas de frequentes bugs descobertos, e exatamente por
esse entre outros motivos, e porque o FreeBSD preza segurança do sistema acima do
conforto do usuário, o Shell padrão do sistema é o (c)sh e não o bash.
Mas não há nada que impeça você de ter o bash em seu sistema, e utiliza-lo com
interpretador de comandos padrão, contudo, recomendamos que você instale o bash2,
que é conhecido com bash seguro. Outra coisa é, apesar de ter o bash instalado, não usa-
lo como interpretador shell padrão em seu sistema. Deixe sempre o (c)sh como padrão,
especialmente para usuários do sistema e utilizados por daemons. Claro que poucos
precisam, e os que precisam de shell, deixe com (c)sh mesmo.
# cd /usr/ports/shells/bash2
# make install
Pronto, seu bash2 será baixando, compilado e instalado. Agora você tem o Bash-2x
instalado em seu sistema, no caminho /usr/local/bin/bash
Para adicionar esse como shell default para seus usuários, no passwd de cada um
deles, ao invez de chamar o /bin/sh, você põe o caminho /usr/local/bin/bash, como no
exemplo:
# vipw
eksffa:w34fgrgll34fI9782lo.:0:0::0:0:Patrick Tracanelli
&:/usr/home/adm/eksffa:/usr/local/bin/bash
#chfn eksffa
Para editar o passwd do sistema, é importante ressaltar, não utilize outro editor, como
ee, pico... porque eles não atualizarão o sistema, e sim apenas o arquivo de referência.
Apenas o vipw e o chfn garante a imediata reconfiguração do database do sistema.
Bom, então porque eu digo que não há necessidades de ajustar os shells default de
cada usuário para bash, e recomendo que não o faça?
A Resposta é a melhor possível: Por segurança. Para usar o shell BASH, basta apenas
digitar bash, mesmo com sh ou csh como shell padrão. Imediatamente você passa a
trabalhar com o BASH, e isso da segurança de restringir alguns usuários a poder fazer
isso, e que um usuário tenha bash, sendo utilizado de modo incorreto.
# bash
Esse comando é o necessário para iniciar o uso do BASH, e mantendo outro shell como
padrão. Recomendamos fortemente que isso seja feito.
Para instalar o GnuLs, você pode utilizar de algum pacote pré-compilado, ou baixar e
compila-lo pelo ports. Para instalar o pacote, caso você tenha o GNULS em CD ou tenha
baixado o Donwload dele, basta usar a ferramenta pkg_add.
Monte o CDRom:
# mount /cdrom
# cd /cdrom/packages/misc/
# pkg_add gnuls*.tgz
Pronto, seu gnuls está instalado.
# cd /usr/ports/misc/gnuls/
# make install
Em seguida o sistema se conectará via FTP em um dos endereços pré definidos e fará o
donwload do código fonte, depois ele compilará e instalará o gnuls, tudo automaticamente.
Pronto, agoura você já está com o gnuls instalado, via package ou pelo ports. Agora é
só providenciar para que, toda vez que você de um LS, ele chame o gnuls com a opção --
color.
Pronto, agora toda vez que você der um LS, o sistema chamará o gnuls com a opção --
color. Kitsch, não? ]:)
Para que isso se efetive automaticamente sempre que você se logar no sistema, coloque
essas aliases dentro do diretório /etc/profile.
Particularmente o que eu mais gosto é o blink. Parece que o sistema fica dizendo vai,
digita um comando, vai quero ordens, vamos, faça alguma coisa... é muito kitsch a
velocidade que o cursorzinho pisca, querendo sempre o próximo comando, eheheh...
# vidcontrol -c blink
No meu caso, e
#vicontrol -c [normal/blink/destructive]
Para fazer o cursor desejado sempre ser iniciado como padrão, prossiga da mesma
forma que para adicionar o mouse em todos os consoles, mas adicione dessa vez a linha
allscreems_flags="-m on -c _nome_do_cursor" da seguinte forma:
# ee /etc/rc.conf
Salve o arquivo, e pronto, na próxima vez que você reiniciar o seu sistema, você terá
Mouse em todos os consoles e terá o seu cursorzinho frenético piscando sem parar.
Coloque o cursor que você desejar.
Bom, aqui a maior dificuldade é o seu modem ser reconhecido pelo Sistema.
Normalmente você terá que recompilar seu kernel novamente, incluindo suporte ao seu
modem, com as DMAs e IRQs corretas. Uma explicação mais detalhada da compilação do
seu kernel de acordo com o seu modem pode ser encontrada no segundo capítulo da
nossa documentação. Parece complicado no início, mas depois de pronto você vai ver que
foi fácil. Vamos rever isso aqui.
Partindo do princípio que você já sabe compilar um kernel no FreeBSD, basta agoura
saber em qual interrupção seu modem opera. Entre no diretório do kernel e edite o seu
kernel.
# cd /usr/src/sys/i385/conf/
# ee ARKIVO_DO_SEU_KERNEL
# cd /usr/src/sys/i386/conf
# ee EEVIACBSD
Bom, eu cheguei no ponto de falar da minha máquina pessoal porque foi lá que eu
configurei pela primeira vez, e o IRQ padrão não funcionou. Por isso, saiba a IRQ do seu
Modem. O Manual, a Placa em sí, ou pelo Windows, são 3 maneiras de saber. Pelo
Windows, veja em propriedades do modem, qual porta e IRQ seu Modem usa.
Nesse caso, vamos configurar seu Modem supondo que ele está na porta COM4 do
Windows, que é a cuaa3 no FreeBSD, ou sio3 para o Sistema. Se Esse não for o seu caso,
basta modificar de acordo com o seu sistema, ou veja no Capítulo 2 esse mesmo
procedimento, mas com mais detalhes.
Finalmente, retire a entrada "disable" e ajuste a sua IRQ.
Prontinho, agora é só recompilar o seu Kernel, e seu sistema responderá pelo seu
Modem.
Mais uma vez ressaltamos a importãncia de conhecer o hardware da sua máquina para
esse tipo de operação. Se você não sabe compilar o seu kernel, ou não se lembra, consulte
o Capítulo 2 da nossa documentação.
Bom, se seu modem já respondia ao seu sistema, todo esse texto acima foi a toa, e
agora sim chega a parte da configuração para se conectar ao seu provedor.
# ee /etc/resolv.conf
domain DOMINIO_DO_PROVEDROR.COM.BR
nameserver IP_DO_DNS_DO_PROVEDOR
search IP_DO_DNS_DO_PROVEDOR
No caso da Fatec:
domain FATECTQ.COM.BR
nameserver 200.210.2.10
search 200.210.2.10
# ee /etc/ppp/ppp.conf
A partir do exemplo acima, as unicas linhas que devem ser modificadas são:
Prontinho, lembrando mais uma vez, modifique apenas o que foi indicado. Algum
espaço no lugar errado pode fazer seu ppp não funcionar, e com certeza o fará. Salve as
configurações do seu ppp.conf e vamos nos conectar.
# ppp
ppp ON EeviacBSD>
Então o ppp irá buscar todas as configurações do ppp.conf na linha referente ao "fatec:"
e irá discar. Depois de conectado, a prompt do seu ppp irá ficar maiúscula, de acordo com
a verificação, autenticação e estabelecimento da conexão, resultando numa prompt
assim:
PPP ON EeviacBSD>
Para desconectar basta digitar "close", para sair do PPP, digite "quit".
Isso quer dizer que sim, você pode ter configurado mais de um provedor para se
conectar com seu FreeBSD, basta seguir as regras para edição do ppp.conf. Veja o
exemplo do arquivo ppp.conf que eu tenho em casa:
default:
set openactive 10
set device /dev/cuaa3
set speed 115200
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \"\" AT \ OK-AT-OK
ATE1Q0
OK \\dATDP\\T TIMEOUT 40 CONNECT"
fatec:
set phone "352 7005"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname eksffa
set authkey eksffaownsthisshittyworld
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
mdbrasil:
set phone "344 5000"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname thamaia
set authkey tha12zmaia
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
zup:
set phone "344 5500"
set reconnect 3 20
set redial 2 20
set timeout 240
set login
set authname desa
set authkey dr12z
set ifaddr 10.0.1.2/0 10.0.1.1/0 255.255.255.0 0.0.0.0
add default HISADDR
enable dns
Isso ajuda muito quando se tem vários provedores disponíveis. Mais uma vez, atenção
com a disposição da configuração. Um espaço a mais ou a menos fará a diferença.
Agora vamos dar uma atenção especial a formas de conexão sem usar esse script de
discagem, o ppp.conf.
Se você quiser fazer a conexão manualmente, basta digitar aqueles dados apresentados
acima no prompt do PPP:
Claro que não existe vantagem aparente nesse processo de conexão, o script no
ppp.conf é mais vantajoso, contudo você pode precisar acompanhar a conexão caso
encontre alguma dificuldade em conectar, o que raramente acontece. O comandoo enable
dns manda ele pegar o servidor de nomes indicado pelo atendedor, alterando assim o seu
resolv.conf
Se ainda assim algum problema que você venha a encontrar não puder ser resolvido,
você deve optar pelo comando set log no PPP, para saber os parâmetros utilize help set
no prompt do PPP; Quanto mais parâmetros você adicionar ao set log mais preciso seu
log vai ser, e mais fácil de descobrir algum problema, contudo, maior o arquivo de log vai
se tornar também. O arquivo de log vai ser gerado em /var/log/ppp.log.
Contudo, o próprio PPP pode dar informações do que está acontecendo, em sua própria
interface. Logo após uma conexão com sucesso, o ppp se torna PPP, então vamos
entender o que cada um desses P em maiúsculo indica:
ppp ON MAQUINA> nenhuma conexão foi estabelecida entre você (cliente) e o servidor
(antendedor RAS)
PPp ON MAQUINA> Agora seu usuário e senhas foram validados e você foi autenticado.
PPP ON MAQUINA> Finalmente agora houve uma concordância de endereços IPs entre
você e o servidor que te atendeu, agora você obteve um endereço IP não-estático que vai
identificar você para o resto do mundo durante toda sua conexão.
Isso vai ajudar muito a entender quando e porque sua conexão não se completou.
Agora você já está apto a se conectar remotamente via PPP na Internet e resolver qualquer
possível problema com essa conexão.
3.6 Rolar a Tela no Console, como SHIFT+PAGE UP/PAGE DOWN em outros Unix
ou clones.
É diferente, mas é extremamente simples. No FreeBSD pra você voltar e rolar a tela do
console, você tem que travar a tela e mover. Para isso, aperte a tecla "Scroll Lock"e use as
setinhas ou as teclas PAGE UP/PAGE DOWN para rolar. Destrave com "Scroll Lock"
novamente, para voltar ao normal.
3.7 Tirando as Mensagens do Sistema que aparecem em todos os Consoles.
Por default, tudo de importante que ocorre com o sistema é logado e impresso na tela. Na
verdade isso é ótimo, pois tem a finalidade de chamar a atenção do usuário que estiver
usando o sistema, para alguma coisa que esteja acontecendo. Algumas vezes são
advertências de erro, outras são informações de alguem que logou no servidor, alguma
tentativa de RELAY, portscanning, enfim, tudo aparece do nada na tela do cidadão que
está na máquina. Perfeito para um Servidor, pra chamar atenção do administrador, mas
algumas vezes isso enche as paciências com mensagens bobas que nós não queiramos
que apareçam no nosso console sem ser convidadas.
Para tirar então todas aquelas mensagens, você deve editar o /ets/syslog.conf
# ee /etc/syslog.conf
Uma delas é bootar o FreeBSD com algum boot qualquer, por CD ou Disquetes. Então,
você entra na parte da instalação em que você define as partições. Não altere nada, e na
saída ele irá perguntar de você quer instamar o BootMgr, enfim, tudo exatamente como
explicado no capítulo de Instalação da Documentação da Eeviac.
Depois saia e aplique as mudanças. Pronto, eis o seu Gerenciador de Boot prontinho
novamente.
Localize esses dois arquivos e copie-os para um diretório qualquer do Windows. Por
exemplo, C:\freebsd\ A seguir, execute o bootinst.exe com o boot.bin como parâmetro:
C:\freebsd\bootinst.exe boot.bin
O aplicativo perguntará em que disco você deseja instalar o BootEasy, e as opções são
0 para o primeiro disco e 1 para o segundo. Prontinho, agora reinicie o seu sistema, pois
você está no Windows, e bem vindo ao gerenciador de Boot, pra você escolher o FreeBSD,
claro... ]:-)
Copiar e colar textos é uma das tarefas mais básicas de um Sistema Operacional. E
nos Unix essa tarefa costuma ser ainda mais fácil que em outros sistemas operacionais,
com o apoio do Mouse. Sabemos que é só marcar o trecho com o Mouse, e pronto, está
copiado. Pra colar é só utilizar o segundo ou terceiro botão. Quer coisa mais fácil? Agora
vamos cnfigurar o nosso mouse de dois botões para copiar e colar no console do FreeBSD.
Para isso, você deve editar o arquivo /etc/rc.conf e adicionar a linha moused_flags="-m
2=3".
Para isso:
# ee /etc/rc.conf
Salve o arquivo, e pronto, a próxima vez que você carregar seu Sistema, você vai sair
copiando e colando feito um louco. Kitsch, não? Mas é essencial.
A função comumente aplicada às teclas ALT+F1, ALT+F2, são agora ESC+F1, ESC+F2,
ESC+F3... (...)
Prontinho, /join #FreeBSD,#radiohead,#Seattle agoura.
Seu mouse só funciona no console principal e isso não anda te agradando? Tudo bem,
isso é normal, e a solução é bem simples. No terminal que você deseja usar o mouse,
basta digitar
# vidcontrol -m on
Se você quer que o mouse seja ativo em todos os consoles pra sempre, ao invéz de
apenas algum console específico, também é fácil. Edite o arquivo /etc/rc.conf e nele
adicione a linha allscreems_flags="-m on"
# ee /etc/rc.conf
Salve o arquivo, e pronto, na próxima vez que você reiniciar o seu sistema, você terá
Mouse em todos os consoles.
Como cada console do sistema é uma Device, então para permitir que seu FreeBSD
trabalhe com mais consoles, você tem que criar as Devices para os mesmos. O FreeBSD
tem um aplicativo que cuida de criar as devices. Ele fica dentro do /dev, onde ficam
também as Devices. Então para criar a device, basta digitar:
# cd /dev
# ./MAKEDEV vty12
Pronto, agora você criou mais uma device para terminal, basta agoura editar o
/etc/ttys
# ee /dev/ttys
#kill -HUP 1
Vamos supor então que você tem 512 Megas de Memória Principal. Edite o Kernel do
seu sistema e inclua ou substitua a linha seguinte:
options "MAXMEM=(512*1024)"
Se você tiver mais, substitua o 512 pela memória total que você tem. Agora compile seu
kernel novamente e pronto. Se você não sabe como compilar seu Kernel, consulte o
Capítulo 2 dessa documentação.
É fácil mudar o editor padrão do sistema para o seu preferido. Se você estiver usando o
interpretador shell csh ou sh, digite:
Exemplo:
# export EDITOR=seu_editor_preferido
Exemplo:
# export EDITOR=pico
Para tornar essa alteração fixa em seu sistema, adicione a linha predefidinida para o
seu shell no arquivo /etc/profile
# ee /etc/profile
Adcione a linha, e salve o arquivo. Prontinho, agora seu editor preferido será o padrão
do sistema.
Assim como no Linux, é possível montar partições FAT no seu FreeBSD, e é possível
também montar partições Linux e algumas outras. Contudo, é necessário que seu sistema
esteja com o suporte aos tipos de arquivos que serão montandos. Esse suporte deve
existir no kernel que você está utilizando. Para ver se a partição que você quer montar é
suportado pelo seu kernel, liste os seus File Systems, usando o comando lsvfs
# lsvfs
Como você pode identificar (espero que possa...) nosso kernel de exemplo não tem
suporte à tipos de arquivos ext2fs. Mas contém à FAT (msdos).
Nesse caso, teremos que adicionar suporte à partições Linux. Faça o mesmo se não
existir suporte à partição Windows. Edite o seu kernel e adicione a linha.
options "EXT2FS"
Agora sim, salve e compile o seu kernel, e eis o seu kernel com suporte à Partições
Linux. Se você não sabe compilar o Kernel, consulte o Capítulo 2 da nossa documentação.
A sintaxe básica para montar sistemas de arquivos diferentes deve ser conhecida:
Para montar uma partição Windows então, vamos criar o diretório que será nosso
ponto de montagem. Nesse exemplo, vamos criar o /windows. Depois montaremos,
supondo que a device da partição windows seja /dev/ad0s2. Vamos então:
# mkdir /windows
# mount -t msdos /dev/ad0s2 /windows
# cd /windows
Pronto, agora você pode ver toda a partição Windows do seu sistema no diretório
/windows do seu FreeBSD. Para montar um disquete, o procedimento é o mesmo,
substituindo as opções. Vamos considerar que seu disquete esteja formatado em Fat
(windows).
# mkdir /diskete
# mount -t msdos /dev/fd0 /diskete
# cd /diskete
Prontinho, agoura nós criamos o diretório /diskete, montamos o conteúdo do disco
flexível nesse diretório, e agora é só trabalhar com ele. No terceiro exemplo, vamos supor
que nosso sistema tenha dois sistemas operacionais, o FreeBSD e o Linux. Ou Três:
FreeBSD, Linux e Windows. Montaremos agoura a partição do Linux no nosso FreeBSD.
Vamos criar o diretório /linux, vamos montar o conteúdo da partição Linux nesse
diretório do nosso FreeBSD e usa-lo. Consideremos que nosso Linux esteja na Device
/dev/ad1s2.
# mkdir /linux
# mount_ext2fs /dev/ad1s2 /linux
# cd /linux
Prontinho, agora você já sabe como montar qualquer coisa que precise em seu
FreeBSD. Talvez o que você não saiba segue um caminho mais técnico. Agora você tem
que saber reconhecer qual device é correspondente à sua partição. Tentaremos explicar
de forma sucinta, como reconhecer seus Devices, sabendo qual partição de qual disco
corresponde ao que.
/dev/xxx
Onde xxx é sempre correspondente às suas Devices. Em caso dos discos rígidos, a
sitaxe mais usual é:
/dev/adxsxx
Vamos tentar entender então. Você tem inúmeros Disco rígidos, com inúmeras partições
primárias e/ou extendidas cada um. Isso tudo tem que ser representado de alguma forma
para o sistema, então vamos ser lógicos como os programadores que desenvolvem o
FreeBSD. Acha que as devices são bagunçadas? Você vai ver que não...
No Exemplo a seguir, vamos considerar que nós temos um Sistema Operacional Linux
na device:
/dev/ad0s2
/dev/ad - Indica que nós estaremos trabalhando com um Disco Rígido. "ad' pode ser
interpretado como "Ata Disk" ou disco gravável padrão ata.
/dev/ad0 - No FreeBSD o esquema dos discos segue o da BIOS, portanto o disco rígido
número 1, no caso do disco for do tipo IDE, seria chamado pela BIOS de IDE0, e portante é
chamado pelo FreeBSD de ATA Disk 0. Então já identificamos que estamos trabalhando
com nosso primeiro disco rígido.
/dev/ad0s2 - Na grande maioria dos casos, nossos disco rígidos, por motivos de
segurança e performance, são particionados. As partições para o FreeBSD são chamadas
de Slices, ou fatias, e cada Slice corresponde a uma Partição. Já deu pra entender agora
então, que nós estamos trabalhando com o disco rígido número 1, e com a segunda
partição.
Essa é a lógica das devices de disco no FreeBSD. Os nomes das devices variam
seguindo essa lógica, e pode variar mais ainda, quando tratarmos de partições lógicas e
primárias, e de discos rígidos do tipo SCSI.
/dev/ad1s2a
/dev/da0s2b
/dev/fd0
Onde, essas variam de Tipo de Discos, SCSI ou IDE, e de partições, e sendo essas
partições primárias, lógicas, secundárias, enfim... e no último caso, o /dev/fd0,
corresponde à device do primeiro disquete. Para entendermos, /dev/fd0 é a Device do
Floppy Disk número 0, ou o primeiro disquete.
Agora você já sabe como as devices do FreeBSD são separadas, e com certeza já pode
identificar cada uma delas. Devemos lembrar que essa explicação foi baseada na versão
4.3 do FreeBSD.
O mais importante agora é você saber em que partição de que disco está qual sistema.
Como você usualmente é quem é o dono do sistema, e deve ter feito todas as partições,
então acho que não existe mais problemas.
disk1s1a>
disk1s1a> boot -s
Mas caso seu FreeBSD seja um Servidor de aplicações e serviços múltiplos, e vários
usuários tenham acesso ao sistema, você mais cedo ou mais tarde sentirá a necessidade
de implementar controle de utilização de disco em seu FreeBSD.
Consideramos que você já compilou seu novo kernel com suporte à opção de QUOTAS no
seu sistema, e também já habilitou seu sistema para conferir as quotas de cada usuário
sempre que necessário, ou seja, já substituiu a opção check_quota='NO' por
check_quota='YES', no seu /etc/rc.conf
Para usarmos as quotas, devemos antes definir em que sistema de arquivo nós
implementaremos esse monitoramento. Para isso, devemos editar o arquivo /etc/fstab e
nele indicarmos a quais partições de sistema de arquivos utilizaremos o controle de quota.
As linhas de identificações devem ser parecidas com a linha a seguir:
Para entendermos, nessa linha eu estou dizendo ao sistema que a partição /usr,
encontrada na device /dev/ad0s1f será um sistema de arquivos de leitura e gravação e
que poderá ter sua quota restrita por usuário.
Você deve configurar seu sistema da maneira que melhor lhe parecer, de acordo com
seus discos e suas partições. Nesse caso setamos a partição /usr para ter seu controle de
quotas monitorado, pois é nessa partição que se encontra o diretório dos usuários de
nosso sistema.
"Os limites aplicados atraves do uso de quotas sao baseados no espaco disponivel ao
usuario em disco (block quotas) e/ou no numero de arquivos por ele mantidos no sistema
(inode quotas). Em ambos os tipos (block/inode) , podemos definir dois limites distintos:
Hard e Soft .
O limite Hard nao pode ser excedido. supondo se que se definui para um usuario uma quota
Hard de 1000 blocos e se atualmente ele esta utilizando 900 blocos ele ira poder alocar
mais 100 blocos, porem ao tentar alocar 101 blocos , a operacao nao sera permitida.
O limite Soft pode ser excedido por um periodo determinado de tempo. Este periodo e
conhecido como perido "grace" e seu default e 7 dias, apos este periodo o limit soft e
convertido em hard e nenhuma outra operacao sera permitida ao usuario, enquanto ele nao
voltar a ficar abaixo do limite Hard. "
edquota -u <usuário>
edquota -g <grupo>
Quando você vai definir ou reajustar alguma configuração de quota, o banco de dados
do sistema de quotas é consutado, e a apresentação desses dados é feita com o editor de
texto padrão no ambiente do sistema. Normalmente esse editor de texto é o 'vi', e para
modificar esse editor padrão, se você estiver usando um interpretador de comandos BASH,
digite:
# export EDITOR=ee
Nesse caso, considerando que você queira definir o 'ee' como o editor de texto padrão
do seu sistema. E caso seu interpretador de comandos seja o default, csh, digite:
# setenv EDITOR=ee
Também considerando que você queira substituir o 'vi' pelo 'ee'. Mais detalhes sobre
esses procediemto de ajuste de editores padrão podem ser encontrados anteriormente
nesse mesmo capítulo.
Para que você possa entender e visualizar melhor nosso exemplo, considere o
/etc/fstab da nossa documentação como sendo:
# edquota -u velouria
Então teremos sempre dados da seguinte forma, em nosso editor padrão:
Podemos identificar então que o usuário velouria, em nosso sistema, pode utilizar até
35000 blocos de disco, cada bloco contendo 1024 bytes. Essa é a matemática para se
definir as quotas. O limite de 35000 é hard, e conforme considerado acima, é o que não
será excedido.
Podemos também verificar que o usuário velouria pode usar até 2000 inodes, ou seja,
2000 nós no sistema de arquivos, e que apenas 100 deles estão sendo utilizados no
momento.
Ainda podemos identificar, que são definidas essas regras para a partição /usr,
conforme configurado por nós anteriormente. Se outras partições tivessem controle de
quotas por usuário habilitado, então elas estariam descritas no nosso editor.
# edquota -g fatecbsd
Quotas for group fatecbsd:
/var: blocks in use: 23422, limits (soft =10000, hard = 150000)
inodes in use: 200, limits (soft = 3000, hard = 42000)
Agora nesse caso, você já pode identificar sozinho os limites de utilização de disco
definidos pro grupo fatecbsd, mas queremos ressaltar nessa documentação, que a
partição em questão não é mais a /usr, e sim a /var, conforme configurado em nosso
/etc/fstab
Essa opção de quotas é extremamente poderosa, e deve-se tomar cuidado para não
definir quotas para usuários de sistema, por exemplo, e que essa restrição de recursos
não faça falta posteriormente.
É dessa forma que você alterará as quotas para cada usuário, ou para grupos. Acredito
que a partir dessa explicação você não encontre mais problema algum. Para verificar as
configurações de quotas utilize o comando quota -v <usuario>
Para mais informações consulte o 'man quota' e tudo que for relacionado, mas isso já é
o bastante para uma configuração básica.
Bom, essa é uma das primeiras atualizações que eu faço à esse capítulo. Agora vamos
tratar de um assunto que com certeza interessa a grande parte dos usuários mais
avançados de sistemas operacionais de Rede. Se nós temos um computador pessoal,
nossa workstation rodando Linux e FreeBSD, e ambos os sistemas utilizam de uma
partição de SWAP, e nunca estão rodando ao mesmo tempo, então porque não
compartilhar o mesmo espaço para SWAP entre os dois sistemas operacionais?
Bom, fazer o Linux usar a SWAP do FreeBSD eu não sei se é possível. Talvez não
porque o Linux requer uma espécie de autenticação especial no tipo da partição para
trata-la como SWAP, mas o FreeBSD pode tratar qualquer partição como espaço para
fazer SWAP. Então vamos compartilhar nosso espaço de forma que o Linux possa
entende-lo como SWAP e o FreeBSD também possa usar esse mesmo espaço pra SWAP.
Por motivos que eu creio estarem bem claros, esse sub-capítulo não é direcionado à
leigos, e não serei mais tão minucioso nas explicações, de forma como ocorre ao longo de
toda a documentação. Esse Como Fazer é destinado a usuários de FreeBSD e Linux, com
um nível médio ao menos de conhecimento nos dois sistemas operacionais.
Eu tive como base para preparar essa documentação um "mini how-to" que pode ser
encontrado em http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/other-
formats/html_single/Linux+FreeBSD.html escrito por Niels Jensen (nkbj@image.dk). Não
posso deixar de citar também o fx do #FreeBSD na Brasnet que me falou desse mini how-
to quando eu precisei compartilhar minha SWAP.
Bom, eu vou procurar documentar com certa atenção e um pouco de detalhe a mais
que no "hot-to" citado, mesmo porque eu encontrei outras dificuldades, que consegui
resolver. Considere que, sempre que eu citar partições, eu configurei o compartilhamento
de espaço em SWAP duas vezes, uma máquina com FreeBSD 4.3-STABLE junto a um
Linux Mandrake 2.2.12 e em outra maquina, com FreeBSD 4.1.1-STABLE com Conectiva
Linux 5.1, na Faculdade. Mas nessa Segunda eu formatei, porque ficou tudo estranho,
acho que errei alguma cousa... Na que tinha fbsd+mandrake tá perfeito até hoje! Mas o
importante disso é frizar que nenhuma vez existia o Windows como terceito sistema
operacional.
Se esse for o seu caso, considere as devidas adapatações nas minhas citações de
partição, e mãos a obra.
A forma como o FreeBSD trata essas partições segue o mesmo esquema dos
tradicionais BSD, portados porém para uma boa convivência com os Computadores
Pessoais atuais, o que lembra de fato bastante o estilo de particionamento de outros
sistemas unix, como Ultrix, Digital Unix, Sun OS e Solaris, além, claro dos irmãos
OpenBSD e NetBSD, que são sistemas UNIX reais.
O FreeBSD não pode ser instalado em uma partição lógica criada pelo Linux ou mesmo
pelo DOS. E ainda, o fdisk do Linux mostras as partições 386/BSD ou BSD sem que você
force pra isso, com o comando "b" durante a execussão normal do fdisk.
Bom, primeiro instale o Linux normalmente, já prevendo o espaço livre que você quer
utilizar pro FreeBSD... lembre-se que o Linux não precisa de uma partição SWAP, então
isso pode ser fundamental na hora de decidir entre fazer ou não essa partição no
momento da instalação, já que se você não fizer, vai entrar no máximo 3 vezes no Linux
sem SWAP.
Bom, mas se você faz mesmo questão da partição SWAP no Linux, então faça ela no
espaço fora da sua partição, ou seja, onde ficará o FreeBSD tão logo você instale, já que
você vai Ter que apagar mesmo essa partição SWAP depois...
Ou se você usa alguma interface mais sociável para compilar seu Kernel, então basta
marcar o suporte a essas mesmas duas entrada, no menu do seu Kernel.
Agora tome cuidado para não deixar de se lembrar de nenhum dos próximos detalhes.
O primeiro, é você instalar o seu novo Kernel, reboote o seu sistema com o novo kernel, e
lembre-se de preparar um disco de boot compatível com esse kernel agora. Faça um boot
novo pro seu Linux. Agora edite o arquivo /etc/fstab e apague a entrada que aponta sua
partição de SWAP no Linux, se é que você criou uma...
# pico /etc/fstab
Agora sim você está pronto pra instalar o seu querido FreeBSD :-)
Agora, depois que sua instalação do FreeBSD estiver completa, reboote o seu sistema e
entre nele com o disco de boot do Linux, que você fez para o novo kernel do linux.
Depois, já no Linux, use o comando dmesg e filtre as entradas dos discos (hd) para Ter
conheciement do seu particionamento atual. O comando deve ser:
# dmesg | grep hd
Ou seja, agoura você pode visualizar onde está todas as suas partições do Linux e as
do FreeBSD...
Nesse exemplo você identifica a partição Linux /dev/hda4 como sendo a sua partição
que está o FreeBSD, e as demais, como as partições contendo o FreeBSD.
Lembre-se que eu comentei pra você se inteirar de qual era a partição de SWAP no
FreeBSD. Se você não sabe, trate de descobrir, e se o particionamento das slices do
FreeBSD foi automática, então a Segunda partição BSD é a de SWAP, ou seja, a hda6.
Sendo assim adicone agoura essa partição de SWAP no Linux, editando o arquivo
/etc/fstab e adicionando a linha:
# pico /etc/fstab
E adicione a linha
Lembra-se que eu disse que o FreeBSD pode usar qualquer partição como espaço para
SWAP e que o Linux necessitava de uma assinatura especial na partição, certo? Para
garantir essa assintatura, você teria que usar o comando "mkswap" sempre que você
entrasse no Linux.
Pra evitar essa chateação, você pode encontrar o script que faz isso na sua inicialização.
Esse script que roda o "swapon", é comumente encontrado no caminho
/etc/rc.d/rc.sysinit
Mas isso pode variar de acordo com as distribuições Linux que você usa. Ache o
arquivo, e, antes da linha com o comando "swap -a" adicione essa entrada:
Isso assinara como partição de SWAP qualquer partição descrita como SWAP no
arquivo /etc/fstab e, se tudo correr bem, isso já é o bastante pra você estar usando seu
Linux e FreeBSD com a mesma partição para SWAP. Use o comando "free" pra garantir o
tamanho da sua partição de SWAP, reboote no FreeBSD pra ter certeza que tudo esta
correto, e se não estiver, você pode ter usado partição errada para definir como SWAP.
Ambos, LILO e BootMgr podem ser usado como gerenciadores de sistema operacional e
gravados na MBR. A escolha é sua... O LILO é mais facil de tratar e menos rigoroso, mas
eu confio mais no BootMgr. Já que você curtiu a idéia de brincar com FreeBSD+Linux
juntos, então leia o próximo sub-capítulo.
Mas enquanto isso não acontece, ou não deixam que você faça acontecer, vamos
analisar outras formas de utilizar o seu Linux da melhor forma possível junto ao FreeBSD.
O FreeBSD tem suporte nativo a diversas ações ligadas a compatibilidade e uso em
conjunto com o Linux, e, apesar do Linux não ser tão competente em tratar o FreeBSD
como o FreeBSD é com o Linux, ele conta com alguns quebra-galhos que podem ser
usados, quando se necessita profundamente do FreeBSD mas tem-se que estar no Linux.
Nós vamos tratar agora de montar as partições com sistema de arquivos do FreeBSD
no Linux. No Capítulo 3.15 você viu que é extremamente fácil fazer a ação reversa, que é
montar ext2fs no FreeBSD, ou seja, montar o Linux no FreeBSD é fácil, porque o
FreeBSD é mais completo. O Kernel mais atual do Linux já tem algum suporte a esse tipo
de ação, mas o ideal ainda é:
Existe outra versão do UFS do Linux, que não necessita nem que suporte a UFS seja
adicionado no Kernel. Essa versão se chama U2FS, e pode ser encontrada no endereço:
http://www.mathi.uni-heidelberg.de/~flight/projects/u2fs/
Lembre-se, nem tudo é festa pra essa solução Linux: O U2FS é bem suportado apenas
para montar sistemas de arquivos para leitura. READ-ONLY FS. Versões para montar
com direitos de escrita existem, mas não são confiáveis, seguras. Eu não recomendo.
Não sonhe tão alto... os pacotes iBCS do Linux dizem que podem fazer isso, apesar de
ninguém ter nunca conseguido.
Em relação aos Unix-Like mais conhecidos (a maioria dos Linux) a atualização e/ou
compilação de um novo Kernel é sempre a atividade mais usual na manutenção de sua
versão e atualização do mesmo. Isso porque "O Linux é apenas um Kernel". Acho que bati
pela primeira vez com essa frase nas listas de discussão sobre FreeBSD, tanto na
Brasileira quanto na Norte Americana (hehe, ok, a culpa da frase é do pessoal da
lista... ;p ), mas não descordei da Frase.
Quando você lê e aprende sobre o Linux, nunca sabe ao certo o que foi, afinal de
contas, que o Linus Torvalds fez... certo? Mas se sabe que não existe um Linux, ou uma
distribuição do Linux que seja mantida por ele. Isso porque ele desenvolveu o Kernel do
Linux, ou seja, o núcleo (ou o "Coração do Sistema" como alguns preferem) desse clode de
sistema Unix para Computadores Pessoais (IBM PC, x86, Intel).
A tarefa de fazer cada Linux o mais recente é a tarefa de escrever suas versões de
sistemas operacionais Linux com o Kernel mais recente... ou seja, é inteiramente baseado
e dependente do Kernel, o trabalho que homens como Alan Cox (Red Hat) e Patrick
Volkerding (Slackware), que é fazer de suas distribuições de Linux as mais adequadas,
para os usuários e seguidores de cada distribuição, em relação ao Kernel. Alguns seres
como o Alan Cox trabalham ativamente junto ao Linus Torvalds no desenvolvimento
também do Kernel, além de suas distribuições.
Por isso nos diversos Linux, a atualização do Kernel é o máximo que se pode fazer em
relação a atualização do sistema. Ter o kernel mais recente é garantia de ter o seu Linux o
mais atualizado possível. Em sistemas computacionais proprietários (como Windows (NT e
2000), Solaris, SCO Unix, IBM AIX, Novell Netware, etc...) não é possível a atualização ou
acesso aos códigos do kernel, nem para uma alteração pessoal, por isso estamos tratando
o Linux em nossos exemplos, por ser um sistema baseado em Unix e por ser aberto
também.
Bem, mas vamos voltar ao FreeBSD. Como você percebeu, a tarefa de compilar e fazer
um novo Kernel, no FreeBSD, é muito, muito mais usual que no Linux. Ao menos essa é a
intenção. Compilarmos o nosso kernel sempre para satisfazer da melhor forma possível as
necessidades de nosso sistema, e nunca termos módulos no Kernel que não
necessitemos... Por isso compilamos um novo Kernel a toda hora no FreeBSD. Com
frequência muito maior que no próprio Linux, que é um Kernel.
Isso garante que tenhamos sempre um sistema enxuto, e sem desperdícios de recursos.
Bem, esqueçamos então o Kernel, e vamos falar do sistema em sí. O FreeBSD permite
que você atualize não só o seu Kernel, como todo o seu sistema. Sim, o código fonte
inteiro do seu FreeBSD pode ser atualizado, garantindo assim que você tenha sempre a
versão mais estável do seu sistema.
Vamos partir do princípio. Quando você instala seu FreeBSD a partir de um CD, ou
uma imagem ISO, ou mesmo via FTP, você está instalando a base do lançamento de sua
versão, ou seja, o RELEASE da versão. Você nunca tem o sistema mais recente, mais
atual e mais confiável, porque versões novas e novas atualizações são apresentadas ao
mundo a cada poucos minutos...
Mas isso também não quer dizer que você esteja instalando um FreeBSD não confiável.
Pelo contrário, o FreeBSD é sempre o melhor que se pode ser de um Unix, e cada -
RELEASE é feito a partir do -STABLE anterior de sua série. Conheço administadores de
sistemas que simplesmente nunca viram a necessidade de atualizar o fonte de seu
sistema... como o administrador da Universidade de Franca (www.unifran.br) por exemplo,
que até hoje está com o FreeBSD 2x RELEASE.
Você pode encontrar diversos servidores ao redor do mundo, que oferecem o códio
fonte mais recente para as diversas versões do FreeBSD. Esses servidores são chamados
de Repositórios Centrais. As versões 2x, 3x e 4x do FreeBSD são as que tem mais ênfase
na atualização de seu fonte hoje.
Basicamente o que acontece com esses códigos fontes dos repositórios centrais é, a
cada atualizaçãozinha que acontece com o FreeBSD, o fonte que foi atualizado é colocado
no ar a mercê dos usuários do FreeBSD. Essas atualizações podem ser desde alguma
coisinha para a melhoria do desempenho do seu sistema, alguns bugs não importantes,
até a descoberta de algum problema (bug) realmente sério em relação a alguma versão do
FreeBSD.
Em síntese, assim que algum Bug em alguma versão do FreeBSD (3x, 4x, 2x) é
descoberto, os desenvolvedores do sistema correm para resolver o problema, e assim que
a correção do Bug está pronta, imediatamente elas são colocadas On Line, nos
Repositórios Centrais. Dessa forma, a única garantia de se ter realmente o FreeBSD mais
estável e seguro possível, é ter a atualização mais recente de seus fontes.
A atualização do Código Fonte do sistema pode ser feita por inteiro, ou por partes,
chamadas de coleções ou módulos. Isso permite que apenas de tempos em tempos você
precise fazer uma parada planejada em seu sistema, para atualização por completo do
mesmo, e permite que você atualize determinado módulo ou coleção que teve um Bug
importante corrigido.
E existem duas maneiras bem práticas de baixar o código fonte mais recente da sua
versão do FreeBSD. A primeira e ideal é utilizando o CVSup. A Segunda, apenas
recomendada em algumas situações, é a utilização do CTM.
O CVSup é o método mais recomendado porque sua ação depende tão somente do
administrador do sistema, já o CTM é uma maneira de atualizar o seu fonte que
independe de você, você configura as ações do CTM, e daí em diante a atualização de
novos fontes é feita automaticamente. Essa última opção é apenas recomendada quando
você não pode ter uma conexão ativa por muito tempo com a Internet.
O CTM. O CTM é um método para sincronização de seu código fonte ideal para
sistemas que não tenham uma conexão constante ou não possam estar conectados por
muito tempo à Internet. Normalmente esse tipo de circunstância é encontrada em
empresas que usam o FreeBSD como servidores de aplicações em sua Intranet, ou
pessoas não muito normais que querem usar seu FreeBSD como Desktop e mesmo assim,
sendo apenas o seu Desktop, fazem questão de ter a versão do seu FreeBSD mais
atualizada possível.
Se você simplesmente não tem uma conexão TCP/IP disponível ativamente pra você,
então o CTM é a melhor maneira de manter o seu sistema sincronizado com a árvore do
fonte dos repositórios centrais ao redor do mundo.
Eu pessoalmente não uso o CTM para atualizar os meus sistemas, mas para escrever
essa documentação eu configurei o meu FreeBSD pra atualizar automaticamente pelo
CTM. Os passos foram seguidos do "The FreeBSD Handbook" e a parte de CTM foi
contribuída por Poul-Henning Kamp <phk@FreeBSD.org>. Entenda esse trecho da
documentação como uma tradução para o português do FreeBSD Handbook, mas um
pouco mais direcionada, já que eu vou citar exemplos e demonstrar o que foi feito.
Bom, existem duas maneiras de se atualizar a árvore do fonte do seu sistema com a
dos Repositórios Centrais, usando o CTM. Uma delas é, se você tiver algum tipo de
conexão direta, mesmo que por um período pequeno de tempo com a Internet, pode
utilizar a forma de atualização via FTP. Se não, pode ajustar seu sistema a receber
automaticamente as atualizações por e-mail.
Essas atualizações são feitas por pequenos arquivos que são enviados a você (ou
buscados, via FTP), e que, usualmente, tem o menor tamanho necessário.
Frequentemente esses arquivos, que são chamados de "deltas", não ultrapassam o
tamanho de 5Kb. Algumas vezes apenas (uma em cada dez) esses pequenos "deltas"
podem chegar a ter entre 50Kb e 100Kb, e invariavelmente muito raramente, chegar a ter
mais que 100Kb. As atualizações são em média de 3 a 5 pequenos deltas por dia, nos
módulos onde essas são mais frequentes.
Uma única vez, a cada sistema que você tem que configurar para atualizar o fonte com
CTM, você precisará baixar um arquivo que tem em média 50MB. Mas essa tarefa é única.
Inicialmente você precisa de duas coisinhas para preparar o seu sistema para receber
atualizações constantes do código fonte. A primeira delas é ter o programa CTM no seu
computador. Desde a versão RELEASE do FreeBSD 2.0 o CTM já está incorporado ao
FreeBSD, usualmente encontrado em /usr/src/usr.sbin/CTM , ou se você não tem o CTM
porque seu FreeBSD é mais antigo que o 2.0 (raramente) ou por algum outro motivo
desconhecido (Murphy), então você pode encontrar o CTM em:
ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm
E os pequenos Deltas para alimentar o fonte do seu sistema. Esses pequenos deltas
podem ser conseguidos via FTP ou por E-Mail. Se você quiser pegar seus "deltinhas" por
FTP, basta se conectar, via FTP em:
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-3/
E se você estiver usando o FreeBSD 4.x, então os deltas necessários ao seu sistema
estão em:
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-4/
ctm-announce
ctm-cvs-cur
ctm-cvs-cur-fast
ctm-gnats
ctm-ports-cur
ctm-src-2_1 (usual e fast)
ctm-src-2_2 (usual e fast)
ctm-src-cur-fast (e usual)
ctm-src-3 (usual e fast)
ctm-src-4 (usual e fast)
Mas vale lembrar que, essa lista pode mudar. Para saber sempre quais as listas
(módulos) disponíveis, basta se inscrever na lista ctm-announce@FreeBSD.org. Depois
para começar a receber a atualização, basta enviar e-mail com o nome-da-
lista@FreeBSD.org e no corpo da mensagem escrever "subscribe nome-da-lista".
Tome cuidado para não se inscrever em listas desnecessárias e receber fontes errados.
Inicialmente você precisa configurar um diretório onde você queira guardar os seus
deltas CTM. Para isso, crie um diretório de acordo com seu sistema. Eu criei um diretório
CTM na partição /usr, e aconselho que você faça o mesmo. Para isso digite no console do
seu FreeBSD, logado como ROOT:
# mkdir /usr/CTM
Pronto. Agoura você vai precisar de um Delta inicial. Esse delta é o maior arquivo com
o qual você vai trabalhar. Por padrão, a cada uma média de 100 pequenos deltas, é criado
um Delta maior, chamado de "src-cur*xEmpty.gz" (onde * corresponde a versão do delta
vazio) e normalmente tem de 25 a 50 Megas, em arquivos no formato ".gz" (compactados)
para economizar espaço em disco. Se você tem o CD da versão RELEASE do seu sistema,
então um "Delta Empty" como esses podem ser encontrados no CD, enconomizando assim
o download de um arquivo grande.
Mas vamos considerar que você não tenha o CD, então terá que baixar o arquivo
"empty" correspondente a sua versão do FreeBSD. Vamos tratar da versão 3.X e da 4.X
que são as que você certamente estará usando.
Para conseguir o arquivo "empty" para a árvore inicial do CTM na versão do FreeBSD
4.X, hoje, 6 de Agosto de 2000, 03:42 da Manhã, você deve baixar o Downloado do
arquivo em:
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-4/src-4.0000xEmpty.gz
O arquivo se encontra hoje com 55,6Mb. A partir do momento que você escolheu o
"Delta Empty" para iniciar a sua árovre CTM, você precisará também de todos os outros
pequenos deltas com numeração superior a ele, os quais podem ser encontrados também
no mesmo diretório do arquivo "Empty" , ou seja, nesse mesmo caso, o endereço FTP é:
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-4/
Vamos agora considerar que você vai atualizar o fonte usando o CTM de um sistema
que use o FreeBSD 3.X; Para conseguir o arquivo "empty" para a árvore inicial nessa
versão, o arquivo que você deve baixar hoje, 6 de Agosto de 2000, 03:44 da Manhã pode
ser encontrado em:
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-3/src-3.0300xEmpty.gz
O arquivo se encontra hoje com 47,8Mb. A partir que você escolheu o "Delta Empty"
para iniciar a sua árvore CTM na versão 3.X, assim como relatado anteriormente, você
também precisará de todos os deltas com numeração maior que ele, os quais também
podem ser encontrados no mesmo diretório do arquivo "Empty" do FreeBSD 3.X, ou seja,
no endereço:
ftp://ftp.freebsd.org/pub/FreeBSD/CTM/src-3/
Agora que você já sabe onde e como conseguir os Deltas iniciais e os Deltas
subsequentes, vamos colocar eles no lugar certo. Considerando que você esteja seguindo
o meu conselho e trabalhando no diretório /usr/CTM então você deve criar mais três
subdiretórios, que são, respectivamente no nosso exemplo: /usr/CTM/deltas,
/usr/CTM/src e /usr/CTM/temp.
# mkdir /usr/CTM/deltas
# mkdir /usr/CTM/src
# mkdir /usr/CTM/temp
Caso você tenha criado um usuário apenas para cuidar dos e-mails da atualização do
sistema, ou tenha utilizado um usuário já existente no seu sistema, como eu fiz com o
usuário "velouria" então basta se logar como esse usuário e executar os seguintes
comandos:
$ su -
$ Password: *****************
Isso fará você se tornar super usuário; isso é necessário para você inicializar a sua
árovre CTM. Note que como usuário "velouria" a prompt da minha shell é representada
pelo caracter "$" e como superusuário, a prompt da minha shell é representada pleo
caracter "#". Agora vamos enfim iniciar nossa árvore CTM. Para isso digite:
# cd /usr/CTM/src
# ctm -v -v ../deltas/src-cur.*
Dessa forma você entrará no diretório dos fontes CTM (/usr/CTM/src), e criará a árvore
CTM a partir dos arquivos Deltas existentes em ../deltas/ (que na verdade é o
/usr/CTM/deltas). Agora sim saia do login do superusuário e volte a trabalhar como o
usuário "velouria", para isso digite:
# exit
Agora sim, como usuário que cuidará da árvore CTM, digite o seguinte comando:
Esse comando vai pegar os e-mails que conterão os Deltas, irá aplicar esses Deltas à
sua árvore CTM, e em seguida apagará os e-mails. O ideal é sempre automatizar o
processo, para isso, você deverá criar dois apelidos de e-mail no seu sistema. Um apelido
de e-mail com o nome de "receiver-ctm" e outro com nome de "owner-receiver-CTM".
Para criar esses apelidos de e-mail e automatizar esse processo, você terá que editar o
arquivo /etc/alias e relacionar o apelido do "receiver-ctm" ao comando "|ctm_rmail -p
/usr/CTM/tmp -d /usr/CTM/deltas -l /CTM/assembly.log" e o apelido "owner-receiver-
CTM" ao usuário do sistema que será responsável pela atualização dos Deltas. Para isso,
logados como superusuário, vamos digitar:
# ee /etc/alias
Para editar o /etc/alias com o editor ee; Em seguida adicione essas duas entradas no
arquivo que esta sendo editado:
Agora salve o arquivo. Para consolidar a criação e apelidos de e-mail, nós devemos
atualizar o banco de dados de e-mail do sistema. Para isso digite:
# newaliases
Agora sim, vamos entender nossas últimas alterações: a primeira alteração relacionará
todos os arquivos que forem enviados ao "receiver-ctm" com o comando que decodificará
todos os deltas que chegarem no sistema, e depois irá instala-los automaticamente a
atualizar a sua árvore CTM, irá deletar os e-mails depois da atualização, e documentará
todas as ações no arquivo ctm.log.
Pronto! Agora você terá automaticamente seu sistema atualizado com o Repositório
Central. Agora basta compilar o seu sistema sempre que desejar aplicar as alterações dos
fontes obtidos através do CTM. Como proceder para atualizar o fonte do seu sistema você
verá a seguir nesse mesmo capítulo.
Lenbrando que a utilização do CTM é recomendada apenas nos casos especiais citados
anteriormente. A utilização do CVSup é mais eficiente, segura e bem mais fácil.
Agora vamos ensinar você a sincronizar o código fonte do seu sistema utilizando o
CVSup. Essa é a maneira mais fácil, eficiente e segura, já que não requer um usuário
recebendo e-mails com arquivos, nem apelidos de e-mail ou qualquer outra complicação
que seja.
Para utilizar o CVSup para atualização do seu sistema, é necessário apenas duas
coisas. A primeira é a instalação do CVSup. A Segunda é editar o arquivo de configuração
com os dados necessários para a atualização do sistema.
# mount /cdrom
# pkg_add /cdrom/packages/All/cvsup-bin*.tgz
# cd /usr/ports/net/cvsup-bin
# make install
O Primeiro comando levará você até o diretório do binário CVSup, dentro do ports, e o
segundo inicializará a instalação, depois disso o sistema baixa sozinho o código-fonte do
CVSup e o compila, criando assim o binário para utilização. Mais informações sobre como
instalar aplicativo portados (a partir do ports) podem ser encontradas no Capítulo 3 desse
documento.
Agora sim você já tem o CVSup no seu FreeBSD. Agora basta apenas criarmos o
arquivo de configuração que conterá as informações necessárias para o CVSup atualizar o
código-fonte do seu sistema.
Vejamos a seguir um como esse arquivo de configuração do CVSup deve ser. Ele deve
conter ao menos as seguintes linhas:
*default host=cvsup3.br.freebsd.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_4
*default delete use-rel-suffix
*default compress
src-all
*default host=cvsup3.br.freebsd.org
Essa linha indica o servidor do Repositório de onde o nosso sistema será sincronizado.
Essa linha indica que a máquina cvsup3.br.freebsd.org será o servidor de onde todo o
código-fonte do sistema será atualizado. A entrada br. no servidor de nomes (DNS) dos
servidores principais da FreeBSD.org direciona o endereço a um servidor que se situa na
nação Brasileira, portanto os Repositórios Centrais mais próximos de nós serão os que
tiverem o sufixo br. no seu endereço. Nesse caso o servidor cvsup3.br foi o que nós
optamos.
*default host=cvsup2.br.freebsd.org
*default host=cvsup4.br.freebsd.org
*default host=cvsup3.freebsd.org
Onde as duas primeiras são outros servidores de Repositórios Centrais para o Brasil, e
a última é uma opção de servidor Fora do Brasil. É um servidor Norte Americano nesse
caso. Uma lista de endereços possíveis podem ser conseguidos no site do FreeBSD
(www.FreeBSD.org).
*default base=/usr
*default prefix=/usr
Essa entrada direciona o CVSup a colocar todos os arquivos de códigos-fonte que ele
atualizar no diretório indicado. É indicado que coloquemos esses arquivos no caminho
onde ficam todos os fontes de nosso sistema, ou seja, no /usr/src, mas como o diretório
src/ já é implícito em todas as coleções (módulos) de atualização, então o correto é
apenas o caminho /usr
Essa opção força o CVSup a atualizar o sistema para o FreeBSD-3.X mais recente e
estável que existir atualmente no Repositório Central. Independente de qualquer coisa, o
mais importante é a versão ser a última estável da série 3.X Atualmente isso
transformaria o seu FreeBSD-XX no FreeBSD-3.5.3-STABLE, que é o mais estável da
série 3.X hoje.
Essa opção faz CVSup do seu FreeBSD pra última versão em desenvolvimento.
Portanto não atualiza para uma versão -STABLE, e sim para uma -CURRENT (corrente
desenvolvimento.
"use-rel-suffix is ... arcane. If you really want to know about it, see the cvsup(1)
manual page. Otherwise, just specify it and do not worry about it."
Em outras palavras, diz pra você colocar a opção lá e não se preocupar com nada. E
pra você checar o Manual do cvsup(1) se quiser realmente saber sobre isso... Eu fui ver
no "man" e lá diz que é pra você confirmar que vai realmente usar as configurações de
RELENG no sufixo indicado... confuso, então desencana e coloca...
A opção "compress" diz pro CVSup utilizar o método de compressão de arquivos do
GZIP. Diz que se sua conexão com a Internet for por um canal T1 (tipo de conexão de
banda larga) ou maior que isso, então não é necessária essa opção. De outra maneira, a
compressão ajuda substâncialmente na velocidade da atualiazação.
src-all
Essa opção diz ao sistema que você vai atualizar todos os fontes, sem nenhuma
exceção. Se a intenção não for atualizar o sistema completamente, módulos específicos
podem ser carregados para a atualização. Isso é muito comum em casos onde você tem
um sistema atualizado a algum tempo, e recentemente aconteceu a descoberta de um Bug
e a possibilidade de "Buffer Overflow" utilizando algum binário de comando do sistema.
Como o "ls" por exemplo.
*default host=cvsup3.br.freebsd.org
#*default host=cvsup2.br.freebsd.org
# Esse endereço acima poderia ser um exemplo de Repositório Central alternativo.
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_3
#*default release=cvs tag=RELENG_4
#*default release=cvs tag=RELENG_3_5
# Os dois Exemplos comentados acima configurariam o CVSup para atualizar o código-
fonte da
# última versão estável do FreeBSD 4, e a outra linha, atualizaria para o FreeBSD 3.5
em
# especial. Mesmo que existisse outra versão 3.X mais recente estável. A que não está
# comentada manda atualizar para a última versão 3.X Estável.
*default delete use-rel-suffix
*default compress
src-all
# Se você não quiser atualizar o seu FreeBSD inteiro, então basta comentar a linha
acima
# "src-all" E descomentar a coleção (módulo) abaixo que você queira atualizar.
#src-base
#src-bin
#src-contrib
#src-etc
#src-games
#src-gnu
#src-include
#src-kerberosIV
#src-lib
#src-libexec
#src-release
#src-sbin
#src-share
#src-sys
#src-tools
#src-usrbin
#src-usrsbin
#--------------------Fim Do Exemplo Do Arquivo De Conf. Do CVSup------------------------
Então basta editar um arquivo de configuração com as entradas que você desejar. Para
criar o arquivo de configuração que melhor satisfaça as necessidades do seu sistema,
proceda da seguinte forma:
# ee /usr/supfile
Onde será criado o arquivo /usr/supfile, e o mesmo será editado com o editor "ee".
Agora basta digitar as entradas necessárias para configuração do CVSup que melhor se
adeque às necessidades do seu sistema. Ou se preferir, basta copiar o exemplo
apresentado acima e fazer as alterações que você julgar necessárias.
Agora basta salvar o arquivo /etc/supfile e se preparar para atualizar o seu sistema.
Agora sim chegou a hora de atualizar seu sistema a partir do CVSup. A linha de
comando para a utilização do CVSup é:
# cvsup supfile
Onde, claro, o supfile é o arquivo de configuração que você acabou de criar. No nosso
caso então, o comando ideal seria:
# cvsup /etc/supfile
Vale lembrar que se você estiver usando o CVSup pela primeira vez, você deve estar
usando ele como superusuário, para que, dessa forma, o CVSup tenha as permissões
necessárias para a atualização por completo do seu sistema. John Polstra
<jdp@FreeBSD.org>, que foi a pessoa que documentou pela primeira vez a utilização do
CVSup, no Manual Oficial do FreeBSD, diz que se você está atualizando sua árvore pela
primeira vez, então é normal que você esteja nervoso, com medo e apreensivo. Tudo bem,
ele fala sobre nervoso, o resto eu que acrescentei.
Se esse for o seu caso, podemos fazer uma prévia da atualização verdadeira. Podemos
rodar o CVSup sem tocar em nenhum arquivinho importante do seu sistema, não
correndo risco algum assim. Apenas uma simulação. Claro que isso não tem graça.
Para isso basta criar um diretório de testes, e depois executar o CVSup indicando para
esse diretório. Para isso faça o seguinte:
# mkdir /var/tmp/teste
# cvsup /usr/supfile /var/tmp/teste
Agora você criou o diretório /var/tmp/teste e depois acionou o programa CVSup para
rodar nesse diretório de testes. Agora o CVSup irá se logar normalmente no Repositório
indicado no supfile mas não irá nem tocar o /usr/src. Ele irá fazer a comparação, e
colocará os arquivos que serão baixados no diretório indicado. A configuração base
também não será modificada. Partindo do princípio que você não precisa ser ROOT para
ler o /usr/src então você também não precisa ser superusuário para rodar o CVSup dessa
maneira.
Se você não estiver usando o X11, pelo fato do seu FreeBSD ser um servidor, ou
simplesmente não gosta de interface gráfica, então você pode usar o CVSup da seguinte
forma:
# cvsup -g -L 2 /etc/supfile
Eu não sou tão radical (pelo contrário, eu amo Enlightenment) quando estou na minha
máquina pessoal, mas em relação a atualizar o fonte do sistema eu prefiro faze-lo do
console. A opção "-g" diz pro CVSup não usar sua interface gráfica. A opção "-L 2" diz pro
CVSup imprimir na tela as saídas de detalhes da operação. Existem 3 níveis de detalhes,
"-L" de 0 a 2. O 2 é o mais detalhado, o Zero não mostra nada, a não ser mensagens de
erros.
# cvsup -H
Mas tudo que você precisa saber já foi explicado. Se você gosta da maneira como o
fonte do seu sistema é atualizado com o CVSup (obviamente essa é a melhor forma) então
você pode cogitar a utilização do CVSup no Cron do seu sistema, mas vale lembrar que
pra usa-lo com o Cron, você deve desbilitar sua interface gráfica.
Mas antes valem algumas recomendações. A primeira delas, é que você precisa de um
bom espaço em disco, em especial na partição /usr para atualizar seu sistema com
sucesso. Em algumas documentações se fala entre 600Mb e 800Mb livres. O meu sistema
tem mais de 2GB livres, mas já compilei em sistemas com 500Mb livres, e nunca tive
problemas.
A documentação oficial do FreeBSD não diz nada em relação ao mínimo de espaço
necessário.
Outra recomendação é fazer o clássico "Make World" do seu sistema logado com o
sistema em Single User Mode (modo monousuário). Para isso, basta digitar, como Root:
# shutdown now
E pronto, o seu sistema mata todos os processos necessários e para tudo, mantendo-se
apenas em modo mono-usuário. A última dica e recomendação, nem deveria ser dada,
deve ser usual na vida de um administrador de sistemas Unix, é fazer backup. Raramente
(nunca soube de ter acontecido) perde-se dados importantes durante a atualização do
sistema, mesmo quando esse falha, mas backup nunca é demais...
Para atualizar seu FreeBSD 3.X, entre no diretório dos fontes do sistema, faça a
compilação/construção do seu novo mundo (sistema) e depois finalmente, instale seu
novo mundo (sistema). Para isso digite:
# cd /usr/src/
# make buildworld
# make installworld
ou
# make world
Pronto, esses são procedimentos que vão demorar muito, muito tempo para terminar, e
quando acabar (depois de várias horas), você terá o mais recente e mais estável sistema
Sistema Unix da Distribuição-Linhagem de Berkeley.
Mas não se esqueça que, antes de reiniciar o seu sistema STABLE, você tem que
recompilar o seu Kernel. Tarefa mole, depois de um Make World. Mas se você não se
lembra como fazer, consulte o Capítulo 2 desse trabalho.
Agora vamos atualizar o fonte do nosso FreeBSD 4.X. O procedimento para isso é
menos simples, mas você se acostuma logo, e durante algum tempo, foi bem difícil se
completar com sucesso... mas parece que o problema era com os Repositórios,
recentemente já está tão simples como deve ser... sem precisar sair lendo logs de erros
para descobrir o que aconteceu...
Na prática:
# cd /usr/src
# make buildworld
# make buildkernel=NOME_DO_SEU_KERNEL
# make installkernel=NOME_DO_SEU_KERNEL
# chgflags noschg /kernel
# cp /kernel /kernel.old
# mv /SEU_KERNEL /kernel
# chgflags schg /kernel
# shutdown now
# cd /usr/src
# make installworld
# shutodown -r now
# cd /usr/src
# make buildworld
# make buildkernel KERNEL=EEVIACBSD
# make installkernel KERNEL=EEVIACBSD
# shutdown now
# mount -t ufs -a
# cd /usr/src
# make installworld
# mergemaster <- nao se esqueca dele... :)
Ótimo! Agora eis o seu sistema Unix com FreeBSD 4.3-STABLE (ou posterior) rodando
maravilhosamente atualizado. Mas lembre-se, na versão 3.X do FreeBSD, você deve
recompilar o seu Kernel antes de reiniciar seu sistema.
4.7 Paciência!!!
Normalmente, em sistemas recentes com uma boa configuração, a operação não deve
levar mais que 5 horas. Em média leva 4 horas. Na minha máquina, um Dual SMP
escalonados @444Mhz e 128Mb de RAM a atualização do meu último FreeBSD 5.0-
CURRENT levou 2,5 horas. O FreeBSD 3.5-STABLE levava menos tempo...
4.8 Anexos.
4.8.1 - Anexo Único:
Toda interface de rede ligada a uma rede TCP/IP é identificada por um endereço IP
formado por 32 bits. Um nome pode ser atribuído a qualquer dispositivo que possua um
endereço IP. A atribuição de nomes aos endereços se deve ao fato de que é muito mais
fácil uma pessoa se lembrar de nomes do que de números. O software de rede entretanto
trabalha apenas com os números.
Na maior parte dos casos, os nomes e números podem ser usados indistintamente.
Desta forma, os comandos telnet freebsd.fatectq.com.br e telnet 200.210.2.11 levam
ao mesmo computador. Quando se utilizam nomes é necessário que exista um serviço que
efetue a conversão deste nome em um número IP para que se estabeleça a conexão.
O DNS, ou Domain Name Service, foi desenvolvido para oferecer uma alternativa à
resolução de nomes através do arquivo hosts.txt que pudesse garantir seu
funcionamento eficiente mesmo em face do crescimento explosivo por que vem passando
a Internet, permitindo ao mesmo tempo que informações sobre computadores novos
sejam rapidamente disseminadas conforme a necessidade.
- Zonas
O termo zona (zone) se refere a informações contidas em um arquivo do base de dados
do DNS.
- Domínio
Parte da hierarquia de domínios, em forma de árvore de nomes, identificada por um
nome de domínio, e sempre sendo um tronco inferior à uma outra árvore de nomes (salvo
em casos extremos, os Top Level Domains ou Nomes de Níveis Altos).
caching-only
Caching-only são servidores que rodam o programa named mas não são fontes oficiais de
informação a respeito de domínios. Estes servidores obtém a resposta a todas as
perguntas que lhe são direcionadas a partir de algum servidor remoto.
Servidores Primários
O servidor primário é a fonte oficial de todas as informações a respeito de um domínio
específico. Ele carrega as informações sobre o domínio a partir de arquivos locais
mantidos pelo administrador do domínio. O servidor primário é o servidor mestre devido
ao fato de que pode responder a qualquer pergunta sobre seu domínio com total
autoridade.
Servidores secundários
Servidores secundários são aqueles que transferem um conjunto completo de informações
a partir do servidor primário. Os arquivos descrevendo as zonas são transferidos do
servidor primário e armazenados no servidor secundário como um arquivo local. Esta
transferência chama-se zone transfer. O servidor secundário mantém uma cópia completa
de todas as informações a respeito do domínio e responde a perguntas com autoridade.
Consequentemente, um servidor secundário também é considerado um servidor mestre.
O resolver é uma biblioteca de rotinas invocadas por processos que utilizam serviços
de rede.
Existem duas maneiras de se configurar o resolver. Pode-se usar a configuração
default, ou criar o arquivo /etc/resolv.conf, modificado para atender às necessidades
locais.
A configuração default utiliza o computador local como name server default e obtém o
nome de domínio default a partir da string retornada pelo comando hostname.
Para que esta configuração funcione o computador precisa estar rodando o processo
named e o seu nome precisa estar corretamente configurado. Se o sistema local não
estiver rodando o programa named, ou se o nome do domínio não puder ser obtido a
partir do comando hostname, faz-se então necessária a utilização do arquivo
/etc/resolv.conf.
Exemplo:
domain fatectq.com.br
nameserver 200.210.2.10
nameserver 200.210.2.11
search fatectq.com.br
5.2.2 Domínios
O InterNIC (Internet Network Information Center), nos Estados Unidos tem a autoridade
para alocar domínios. Para obter um domínio, o interessado precisa submeter um pedido
ao NIC para criar um domínio sob um dos domínios de alto nível (net, gov, mil, org, com,
edu).
A InterNIC permite a aplicação de regras próprias para o registro dos domínios em todo
o mundo, portanto as regras para se registrar um domínio delegado sob o Top Level .br
são diferentes das formas de registro de outros domínios, não representados pela Fapesp.
Se o servidor de nomes não for o servidor oficial do domínio a respeito do qual se quer
obter informações, ele terá que perguntar a outros servidores de nomes até obter a
informação solicitada. Ele poderá enviar perguntas recursivas a outros servidores,
obrigando-os a obter a resposta e retorná-la, ou poderá enviar perguntas iterativas se
aproximando de outros servidores que estejam mais próximos do domínio que está
procurando.
5.4.2 Resolução Iterativa
A resolução iterativa não requer tanto trabalho por parte do servidor de nomes
consultado. Na resolução iterativa, o servidor de nomes retorna ao cliente a melhor
resposta que já conhece. Não existem perguntas adicionais.
O servidor de nomes consultado pesquisa seus dados (inclusive o seu cache). Se não
encontra a informação desejada entre estes dados, ele tenta fornecer ao cliente (resolver) a
melhor informação que puder que possibilite a continuação da resolução do nome
desejado. Normalmente esta informação consiste de nomes e endereços de servidores que
estejam mais próximos dos dados que se procura.
A maior parte das entradas nos arquivos de banco de dados do DNS são chamadas de
Resource Records. As pesquisas feitas pelo DNS ignoram se as letras são maiúsculas,
minúsculas ou misturadas. Normalmente se utilizam apenas letras minúsculas. Os RRs
precisam iniciar na primeira coluna.
SOA - Marca o início de uma Zona com autoridade máxima sobre o Domínio referido.
Sintaxe ordenada é o Domínio em questão, o endereço de domínio do admin, um número
serial e os parâmetros Refresh, Retry, Expire e TTL Mínimo, em segundos. Para mais
informações veja a RFC 883 e RFC 2808.
CNAME - Nomes canônicos (para aliases) - Canonical Names são os Apelidos referidos na
configuração de um Servidor de Nomes.
HINFO - Host Information. Informações sobre o Host, como qual o Sistema Operacional.
Fonte de informações para essas entradas foi o FreeBSD System Manager’s Manual
NAMED(8)
Internet domain name server (DNS) - Para mais informações, digite no seu FreeBSD: man
named
5.5 Arquivos de Configuração
Outras vezes esses padrões são adotados devido ao sistema que você está usando. Mas
o mais importante é você ter em mente que as configurações do seu DNS, é você quem faz,
portanto o mais importante é entender como funcionam os arquivos utilizados para que,
qualquer leitura de um outro servidor de nomes possa ser facilmente assimilada. Você
pode ter um padrão próprio de configuração.
Para isso, devemos entender a ordem que os arquivos hierarquicamente são invocados.
Quando se inicia o servidor NAMED, o primeiro arquivo que você deve mostrar a ele é um
arquivo de configuração básico, que contém informações que dizem, qual é o diretório
padrão onde o servidor de nomes deverá trabalhar seus arquivos. Depois disso, esse
mesmo arquivo também indica quais outros arquivos, e de que tipo eles são, que devem
ser procurados para determinada finalidade. Você entenderá isso de forma clara a seguir.
O Passo seguinte, é o servidor de nomes carregar todos esses arquivos de configuração
indicados (no caminho indicado no início do arquivo, sob a directiva directory{}).
Nesse momento então, se o conteúdo de todos esses arquivos for interpretável pelo
named, então seu servidor de nomes deverá estar rodando. Interpretável porque, aqui sim,
o conteúdo das informações deve seguir uma padronização que o servidor de nomes
entenderá.
Os named mais novos, no entanto, adotaram o arquivo padrão a ser procurado como
sendo o named.conf, uma opção mais considerável, na minha opinião. Outra grande
diferença é que, em sistemas Unix System V, esse caminho também é o /etc/named.conf,
porém no FreeBSD, o named trabalha no diretório /etc/namedb ou seja, então ao ser
iniciado, o named procura pelo arquivo /etc/namedb/named.conf, para então carregar
toda a configuração de serviços de nomes.
Se você nunca trabalhou ou viu alguém configurando um servidor de nomes está
achando essas informações todas desordenadas, mas tente apenas entender o conceito,
pois a prática é bem associável a ele.
Essa é uma das difereças que cabe a você adotar ou não, de acordo com seu tipo de
administração. Eu adoto o padrão /usr/named, ou /usr/home/named. O porque deu
fazer isso é, algumas vezes segurança (como quando rodo o BIND chrootado, por exemplo)
e outras vezes, também por segurança, hahaha xsxsxsx Prometo esclarecer esses pontos
adiante. Agora vamos continuar com a implementação em sí.
A última difereça é como nomear os arquivos. Com o Servidor de Nomes, nós estaremos
trabalhando com alguns tipos diferentes de arquivos. Arquivos de Base de Dados de
informações sobre a máquina servidora, base de dados do domímio pelo qual nosso
servidor de nomes tem autoridade, base de dados de domínios virtuais dos quais nós
também temos autoridade, base de dados de relacionamento global, com os Root Name
Servers e com outros grandes servidores de nomes importantes (que é o que fará nosso
servidor de nomes se comunicar com os principais servidores ao redor do mundo), ainda,
com informações sobre a interface local de nomes, e por último, trabalharemos com
informações reversas de tudo isso sob o que nós temos autoridade.
A grande questão é, todos esses arquivos, são arquivos de texto, e como nos Unix não
existe distinção de arquivos por extensão, a forma como você nomeia seus arquivos deve
ser sua maior aliada na organização do seu servidor de nomes.
Dois arquivos porém não devem ser tratados com outros nomes. Não que não possa,
apenas não é indicado. Estes são, o named.ca que é o arquivo que colocará o seu servidor
de nomes em contato com os outros servidores principais ao redor do mundo, e o
named.local, contendo informações sobre a máquina servidora de nomes. No caso a sua
máquina.
Para organizar a minha vida, eu costumo tratar todos os arquivos de Data Base (dase
de dados) da seguinte forma: db.identificação. Ou seja, de acordo com o que eu vou usar,
eu mudo a identificação, dessa forma, os meus arquivos de DNS ficam, por exemplo,
db.dominio, db.XXX.XXX.XXX, db.dominio-virtual, db.outracoisqualquer, e apenas o
named.ca e named.local ficam intactos. Essa na minha opinião é a melhor forma de
identificar meus dados.
Domínio: eeviac.com.br
Servidor Primário: eeviacbsd.eeviac.com.br
Servidor Secundário: xffa.eeviac.com.br
Segundo Secundário: corduroy.eeviac.com.br
Faixa de IPs da Rede: 200.230.200.0 até 200.230.200.63
Portanto Máscara: 255.255.255.192
5.5.1 /etc/namedb/named.conf
# named
Fará com que o BIND seja inicializado utilizando a informação contida no arquivo
/etc/namedb/named.conf
Já o comando:
# named -c /usr/local/algum_diretorio/named/named.conf
Fará com que o BIND seja inicializado com a informação contida no arquivo
/usr/local/algum_diretorio/named/named.conf
Mas a maioria dos sistemas Unix utiliza esta convenção, de sempre manter o arquivo
de inicialização do named onde ele procura por default, evitando usar a opção -c ou
apenas fazendo uso dela pra ter certeza de estar iniciando o named da forma correta. O
arquivo named.conf abaixo exemplifica a configuração de nosso servidor, como se fosse
um site pequeno, com apenas um domínio e apenas uma classe C:
options {
directory "/usr/named/";
query-source address * port 53;
};
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "eeviac.com.br"{
type master;
file "db.eeviac";
};
zone "0-63.200.230.200.in-addr.arpa"{
type master;
file "db.200.230.200";
};
HINT - Informa ao named onde se encontra a lista dos root nameservers utilizada para
fazer a inicialização de seu cache.
MASTER - Pode ser utilizada diversas vezes, e sinaliza ao named quais são os domínios
para os quais possui informações oficiais (authoritative).
Dessa forma, vamos analisar agora, como trabalharia o nosso arquivo named.conf, se
utilizassemos esse pequeno exemplo apenas para o nosso domínio:
options {
/* declara que estamos iniciando uma opção que deve
* ser interpretada pelo nosso servidor de nomes
*/
directory "/usr/named/";
/* indica que a opção aberta na linha
anterior vai apontar
* pro nosso servidor de nomes o diretório
padrão, onde ele
* vai encontrar todos os arquivos que serão
referenciados
* a partir de agora, nesse mesmo arquivo
*/
query-source address * port 53;
/* é uma Segunda opção, repare que a TAG options{}; ainda
* não foi terminada, ok? Bom, essa opção indica ao NAMED que ele
* responderá ao BIND, quando esse fizer
perguntas na porta 53
* o porque disso? No FreeBSD agora
pode-se definir outras
* portas para trabalhar de maneira mais eficiente com firewalls.
*/
};
/* agora sim, a tag options {}; está terminada. */
zone "." {
/* Lembre-se: a intenção é você aprender, ao invés de simplesmante copiar
* então atenção a essa diferença, agora a tag não foi iniciada com a
* mesma sintaxe que anteriormente. A directiva ZONE trata da Zona
* referenciada, portanto, antes se indica de que zona você está falando
* aí sim abre a tag {}; para inserir as opções. Nessa linha estaremos
* trabalhando com os domínios absolutos, a raiz de todos os servidores
* de nomes. Ou seja, os Root NameServers, como já vimos antes.
* Então, para indicarmos que é a zona mais alta possível, usamos a
* directiva "."
*/
type hint;
/*
agora estamos indicando que essa zona é do tipo hint, lembra-se da
* tabela que vimos acima? Nosso servidor entrará em contato com os Root
* NameServers para prepar o nosso cache de resolução de nomes.
*/
file "named.ca";
*/
};
zone "0.0.127.in-addr.arpa" {
*/
type master;
/* tipo de entrada ‘master’ na tabela acima. Master, lembrando
* que for preciso indicar uma zona pela qual nós respondemos
*/
file "named.local";
/* Bom, aqui estamos indicando que as informações sobre essa
*/
};
/* Mais uma vez, terminando a directiva. */
zone "eeviac.com.br"{
/* Como já entendemos a sintaxe da directiva zone ""{}; então já
*/
type master;
*/
file "db.eeviac";
*/
};
zone "0-63.200.230.200.in-addr.arpa"{
* a sintaxe: zona do tipo reversa, dos clientes 0-63 (Zero até 63) da rede
* Como nós somos os responsáveis por esses hosts devemos prover também
* terá que conter informações reversas (se você leu com atenção as
* tabelas anteriores, já pode imaginar que elas serão referenciadas usando
*/
type master;
/* É claro que nós respondemos com autoridade pelo reverso da nossa rede
*/
file "db.200.230.200";
/* e esse é o arquivo que contém a Base de Dados reversa da
*/
};
ATENÇÃO: No BIND 9 a informação sobre a zona reveresa não deve ser apresentada na
forma
Essa sintaxe também pode ser adotada no BIND 8.2.4 e superiores, não comprometendo a
eficiência das informações.
5.5.2 /usr/named/named.ca
Este arquivo contém a informação necessária para se inicializar o cache com os dados
relativos aos Root Nameservers.
# ncftp ftp.rs.internic.net:/domain/named.root
Dessa forma você pode visualizar a facilidade em criar um script que atualize sozinho,
junto ao cron, as informações sobre os Root Nameservers! Bom, agora vamos dar uma
olhada no arquivo. Essa é a descrição do arquivo named.ca atualizado via FTP, na data
de 22 de Agosto de 1997. Um tanto velhinho, mas não mudou nada. Até a data atual
(Maio de 2001) você pode usar esse arquivo com tranquilidade.
5.5.3 /usr/named/named.local
Seguindo a ordem de inicialização do nosso servidor de nomes, agora o named.conf
chama a interface reversa de Loopback, e aponta para o arquivo named.local para obter
os dados. Então vamos entender agora a função do arquivo named.local
O FreeBSD tem um script em PERL dentro do diretório /etc/namedb que cria esse
arquivo automaticamente para a sua máquina. Facilitando assim o seu trabalho e não
necessitando que se faça um arquivo na mão. Esse script em PERL vem sem permissões
de execussão por default, portanto de essa permissão (chmod +x) e execute o script.
;
; BIND data file for local loopback interface.
;
@ IN SOA localhost. root.localhost. (
98101401 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS localhost.
1 IN PTR localhost.
;
;
Acompanhe agora com a tabela dos Resource Records (RRs - Capítulo 5.4.3), e vamos
entender então quais os dados e como estão sendo passados para o nosso servidor de
nomes. Lembrando que nós estamos tratando de uma zona do tipo master, ou seja, onde
nós temos autoridade e responsabilidade total sobre os dados que estamos tratando.
Felizmente essa é a interface de Loopback, mas o rigor das informações é o mesmo para
outras zonas da Internet as quais nós tenhamos autoridade. Vamos então acompanhar o
arquivo, seguindo o mesmo esquema do named.conf onde as observações estarão na cor
amarelo escuro.
;
; BIND data file for local loopback interface.
;
$TTL 14400
@ IN SOA localhost. root.localhost. (
; da entrada SOA, que era o Domínio da Zona em questão, o edereço de domínio do admin
; em segundos, certo? Como você pode ver, a sintaxe toda está referida aqui.
; O arquivo inicia com uma @, @ em inglês se pronuncia como a conjunção "at" que
; que é como se fosse, traduzindo livremente, como a conjunção "em" na nossa língua
; ou seja, referenciamento de lugar, local. Foje ao assunto desse capítulo, mas vamos
; a uma breve adenda: É por isso que os endereços de e-mail tem o formato
; Bom, voltando. Inicialmente, com o BIND antigo, era preciso usar uma arroba (@) antes
; de anunciarmos a entrada (IN) da zona que estamos tratando. Hoje em dia a arroba (@)
; Então agora já sabemos que na linha cima estamos apontando uma entrada (IN) ao
nosso
; servidor de nomes, e depois percebemos que essa entrada é do tipo Autoritativa, ou seja,
; nós temos total controle sobre ela. A seguir então segue-se a ordem da sintaxe dessa
; entrada SOA, primeiro o domínio da Zona em questão, que nesse caso é a zona
; funcionamento do nosso servidor de nomes será enviada a ele. No nosso caso, ele é
; da mesma forma que nos conectamos aos Root Nameservers para fazermos
; uma verificação e criar o nosso cache com dados sobre nomes, claro que
; temos autoridade sobre um (ou vários) domínios importantes, então tudo que
; sobre nós.
28800 ; refresh
; Bom caso não alteremos o serial do nosso servidor de nomes, existe um tempo, em
segundos
; que nós forçamos a sincronia dos nossos dados com os outros servidores de nomes do
mundo.
14400 ; retry
; Caso não consigamos exportar ou importar novos dados, existe um tempo, também em
segundos
3600000 ; expire
; Esse é o limite para os dados no servidor de nomes e pra sincronia entre nós e o
86400 ; default_ttl
; Default TTL (Time To Live) é o tempo de vida padrão para uma requisição de nome ser
resolvida
; Depois desse tempo a requisição morre... essa entrada para default_ttl é usada se o noss
arquivo
; fecha o parênteses, porque acabou os dados requeridos para a entrada (IN) autoritativa
(SOA)
@ IN NS localhost.
; Nessa linha, estamos indicando uma entrada (IN) de um servidor de nomes (NS) com
autoridade
; sobre o o Domínio (zona) em questão. O Servidor de nomes (NS) com autoridade sobre a
; linha esta indicando que ela será servidora de nomes para a zona dela mesma.
1 IN PTR localhost.
; temos em mente que a zona que estamos trabalhando é a de loopback, então só existe a
; nossa própria máquina nessa zona, portanto o cliente (host) número 1 somos nós. De
uma
; olhada na tabela de RRs para ver como declaramos endereçamento reverso dos hosts de
uma
; zona e você vai lembrar que pra isso usamos os Ponteiros (PTR) apontando o host ao
nome.
; Portanto a primeira máquina de noss zona (1) é uma entrada (IN) do tipo reversa, que
aponta
E eis o final do nosso arquivo named.local, que indica a nossa zona e reverso da
interface de Loopback. A importância dessa identificação é a segurança que a
identificação de uma zona inteira a um único host pode oferecer, sendo esse único host o
próprio servidor de nomes.
Dessa forma, antes de sermos apenas mais um host de uma zona que temos
autoridade (o que você verá a seguir) somos o único host de uma zona própria também.
Ou seja antes de sermos o nosso endereço IP real para o resto do mundo, nós somos o
127.0.0.1, e isso traz segurança à varios tipos de configuração.
5.5.4 /usr/named/db.eeviac
Como nós temos informações oficiais sobre a zona ‘eeviac.com.br’ então ela é do tipo
master, que é a forma como é apontada no named.conf, e toda informação sobre essa
zona do tipo master está contida na base de dados que é chamada pelo mesmo arquivo de
db.eeviac. Poderia ser eeviac.zona ou zone.eeviac de acordo com a forma que cada
administrador implementa.
É esse db.eeviac que nós vamos analisar agoura. Segue um exemplo de como deve ser
o arquivo:
$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
@ IN NS xffa.eeviac.com.br.
@ IN MX 10 smtp.eeviac.com.br.
@ IN MX 20 xffa.eeviac.com.br.
@ IN A 200.230.200.10
rt IN A 200.230.200.1
ras IN A 200.230.200.2
eeviacbsd IN A 200.230.200.10
smtp IN A 200.230.200.10
; smtp IN CNAME mail.eeviac.com.br
pop3 IN A 200.230.200.10
; pop3 IN CNAME mail
ftp IN A 200.230.200.10
; ftp IN CNAME wwwfserv.eeviac.com.br
www IN A 200.230.200.10
; www IN CNAME wwwfserv
host3 IN A 200.230.200.3
maq4 IN A 200.230.200.4
maq5 IN A 200.230.200.5
host6 IN A 200.230.200.6
ma7 IN A 200.230.200.7
eeviac8 IN A 200.230.200.8
xffa IN A 200.230.200.9
corduroy IN A 200.230.200.11
eev12 IN A 200.230.200.12
Como você pode ver, esse arquivo agoura é bem completo, e contém vasta informação.
Na verdade, esse arquivo não contém apenas as informações de nomes da sua zona
(domínio) mas também toda informacão de nomes dos clientes (hosts) da sua rede ou
zona. Essa informação é o relacionamento de um nome, dentro da sua zona, ou um
apelido (ALIAS) de um nome dado para outro host, o que é chamado de Nome Canônico
(CNAME). Vamos então acompanhar e entender cada linha do arquivo de base de dados
que representa toda informação para zona eeviac.com.br:
$TTL 14400
; Tile To Live à ser usado. Não é obrigatório, se essa opção não existir o
; no nosso servidor de nomes, e a entrada é do tipo que nós temos total autoridade,
; da zona, que no exemplo anterior era a zona localhost, e agora a zona é a zona da
; na internet representada por eeviac.com.br será respondida por nós. Nós temos
autoridade
; No entando, vamos fazer uma pausa para um detalhe que eu propositalmente deixei de
; comentar quando comentamos o arquivo named.local; Se você reparar, o domínio da
zona é
; terminado por um ponto final, sempre que esse é referenciado. Veja o trecho:
; que é um domínio absoluto, ou seja, depois do ponto nunca vai existir mais nada. Na
; prática, nunca vai existir um host depois da zona referida, assim, nunca existirá uma
; máquina com nome eeviac.com.br.host1 por exemplo. Poderá, e existirá sempre um host
; antes, mas nunca depois, sendo, um host, um nome canonico com o nome de www
; ao nosso domínio, mas não é tanto. Vou fazer mais uma adenda, mesmo sabendo que
vou
; me extender sem necessidade, mas por curiosidade, vou comentar... Até o final do
primeiro
; Fundação Amparo (FAPESP), que é o orgão responsável pelos nomes no Brasil, não
entendia
; referenciavam isso, achando que os domínios absolutos diretos (.com, .net, .org, .gov,
etc)
; Brasileiros, mesmo que contivessem um ponto final no fim da zona. Bom, onde eu quero
; chegar com isso? Por causa desse probleminha que quase passou em branco por mais
tempo
; Existe uma ceita Americana de Sado Masoquismo e Cultura Negra (satanismo) que se
chama
; Black Rose, ou Rosa Negra. E o domínio dessa ceita na Internet é br.org . Até então tudo
bem
; mas pelo fato dos Root Namerservers acharem que acima do nível .br ainda poderia
existir
; outro dos absolutos, então toda vez que um domínio .br era sucedido de um .org (por
exemplo
; Rose .Org e dizia que o endereço correspondente não pode ser encontrado nos servidores
deles.
; Ou seja, sempre que fizessemos isso com algum domínio, então caíamos nas páginas de
BDSM
; Sado Masoquista e Satânicas da Black Rose. Não sei até que ponto isso era
desconhecido, mas
; quem falou disso comigo foi um grande amigo, o Ric Milk (ASBYTE). Quando
descobrimos isso,
; nós saímos correndo tentando registrar br.net, br.com, jp.net. jp.org, fi.net
; e outras... Mas não deu certo... e o Leite mandou uma série de e-mail pra Fapesp e
; Internic dizendo que isso estava acontecendo... Quem sabe não arrumaram isso por
2000041003 ; serial
; Esse é o serial da nossa zona eeviac.com.br, você se lembra da descrição dele no arquivo
; named.local certo? O Número serial costuma ser formado da data e da ação, assim, esse
; número serial estaria representando o serial da terceira alteração feita em 10 do mês
; 04 do ano 2000. Mas na verdade isso é uma adoção apenas, e não tem que ser levada
; pode ser até pontuado, mas que é algo desnecessário devido ao fato da tradução
; dos Inteiros reais serem via concatenação, e não via multiplicação ou adição. Diz ainda
que você
; pode escrever o mês, o ano e o dia do mês, que ainda assim esses serão dados dentro do
; padrão que o BIND entende, que é de 32 bits, se bem que isso terá que ser repensado
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
; E esse é o valor mínimo para o TTL (Time to Live) que o servidor permanecerá insistindo
; com uma requisição com resposta negativa, caso outro valor não tenha sido previamente
)
; Fecha o parênteses porque é o fim da configuração obrigatória de todos os parâmetros
@ IN NS eeviacbsd.eeviac.com.br.
; Lembra-se que, de acordo com a tabela dos Resource Records (RRs) a entrada para se
; referenciar um servidor de nomes é NS (de Name Server), então nessa linha estamos
; portanto essa é a máquina que estará nos servindo, ou seja, eeviacbsd é essa mesma
; estação (host) que nós estamos configurando, portanto a primeira entrada dos servidores
; de nomes padrão no nosso DNS é nós mesmos. Detalhe no ponto final ao final do
domínio.
@ IN NS ns.embratel.net.br.
; Podemos Ter mais que um servidor de nomes configurado em nosso DNS, e esse
segundo
; de nomes no Brasil, ou seja, esse servidor de nomes será consultado sempre que não
@ IN NS xffa.eeviac.com.br.
; Ter mais que um servidor de nomes e um secundário, ou seja, você deve sempre
configurar o
@ IN MX 10 smtp.eeviac.com.br.
; de um domínio (zona) da Internet. Imagina-se que por todos os domínios que nós
; tenhamos autoridade queira-se poder configurar e-mails para essas zonas. Dessa forma
; devemos indicar o(s) servidor(es) de e-mail que responde(m) por nossa(s) zona(s).
; ou Mail eXchanger (MX) com preferir, para que possa receber as mensagens
; número indica a preferência (0..99) que o servidor tem, em caso de existir mais
; de um servidor que responde pelas zonas que temos autoridade. Esse valor é
; outros servidores de e-mail (MX) ele tem. Dessa forma, se tivermos 2 ou 3 servidores
@ IN MX 20 xffa.eeviac.com.br.
; referenciado, mas com uma prioridade mais alta que o primeiro, como
; se responsabilizar por entregar esse e-mail. Ele pergunta ao seu servidor com
; menor entrada (no nosso caso smtp.eeviac.com.br, com entrada 10) e esse
; servidor diz que não reconhece esse usuário desse domínio. Então seu servidor
; passa a requisição para o próximo servidor que ele conhece, com a próxima entrada
; mais baixa, no caso a entrada 20, que aponta o servidor xffa.eeviac.com.br; Se esse
; (pixies) então o e-mail esta entregue. Mas se esse servidor de e-mail também não
; responde por esse usuário e/ou zona (velouria.com.br) e não existe outro servidor de
; e-mail cadastrado no seu servidor DNS (uma terceira entrada -IN- de servidor de mail
; -MX- com um valor maior que o último consultado), então uma mensagem de erro
; é enviada ao remetende do e-mail, dizendo que não pode entregar o e-mail, ou seja,
@ IN A 200.230.200.10
; ou seja resolver eeviac.com.br pro endereço IP em questão. Essa entrada diz que
; as configurações acima criadas são referentes à aquela náquina, e demonstra o
; endereço Quartenário dela. Isso evita que o DNS precise ser consultado para
; Agora sim começa um dos serviços mais importantes de nosso servidor de nomes,
; você se lembra da introdução desse capítulo que diz que as máquinas conversam entre
; si usando os endereços IPs a nível de software e hardware, mas que isso é transparente
; para o usuário leigo, certo? E você viu que, até agora muitas vezes nós fizemos
; e o resto? É agora que vamos tratar dos nomes dos clientes... ( os hosts ).
rt IN A 200.230.200.1
; primeira entrada que não precisa ter o nome da máquina (host) e hoje em dia nem a
; arroba é mais obrigatória, e que nós já vimos pra que serve essa entrada) é:
; O nome da máquina sob a zona primária, referenciando uma entrada (IN) do tipo
; endereço Quartenário IP (A) e apontando esse endereço quartenário. Vale lembrar que
; um servidor de nomes com endereço IPv4. Isso quer dizer que o nome completo do
endereço
; daquele host derá o nome dele + a zona autoritativa sobre a qual ele pertence.
; vai ser o nome do host mais essa zona. Nessa entrada acima, estamos então dizendo que
; o nome "rt" é uma entrada (IN) pro endereço IP quartenário (A) referente a 200.230.200.1
ras IN A 200.230.200.2
; Essa próxima entrada quer dizer... a mesma coisa, mas faz referência de nome de outra
; máquina a outra entrada quartenária. No Caso, essa entrada diz que o nome "ras" é
; Uma dica, para melhor performance da sua rede em relação ao servidor de nomes (DNS)
é
; sempre usar os hosts mais baixos da sua rede para serem as máquinas com maior
requisição
; ou seja, os servidores. E se houver alguma máquina que seja servidor, e o host (IP) dela
seja
; superior a o de um host menos importante, então indique ela antes nas suas entradas
DNS.
eeviacbsd IN A 200.230.200.10
; Nesse caso escolhemos o primeiros host de nossa rede (200.230.200.1) para ser o nosso
; servidor de rotas, ou seja o nosso roteador, por isso o nome "rt" O Segundo IP/host é o
; nosso Autenticador Remoto (RAS) por isso o nome "ras" (IP 200.230.200.2). O RAS é o
; provedor de acesso INTERNET. Essa terceira entrada, não é a do host 3, mas sim a do
; principal, onde está rodando, entre outras coisas importantes, esse servidor de nomes
aqui.
; A entrada diz que o host com nome "eeviacbsd" é uma entrada (IN) para o endereço IP
smtp IN A 200.230.200.10
; Essa entrada diz que a máquina com nome de smtp (que foi referenciada lá em cima)
; pode, mas não é o indicado, ou não é o ideal. Para esse tipo de ação, prover
; Agora estamos vendo o que seria a forma ideal de se prover aquela entrada acima.
; Por isso em cor vermelha, em Itálico e com asterisco (*) antes da entrada. Essa entrada
; não deveria existir no nosso arquivo, porque existe a de cima. Ela está aqui por motivos
; didáticos, portanto quando você for fazer o seu DNS, escolha por apenas uma forma de
; atribuir outro nome à mesma máquina. A Sintaxe dos nomes canônicos é, o nome
referente
; aquele nome será um apelido. Podemos apontar uma máquina fora de nossa rede,
podemos
pop3 IN A 200.230.200.10
; Essas duas linhas acima fazem de novo as referências que eu acabei de comentar,
lembrando
; que o ideal é a Segunda entrada. Escolha uma delas e substitua pela outra, deixando
apenas uma
; no seu DNS, e detalhe na sintaxe, agora aponta apenas para o nome do host (eeviacbsd)
e não
ftp IN A 200.230.200.10
; Mais dois exemplos para garantir que você entendeu esse conceito de nomes
; distindos para a mesma máquina. Vamos supor que você tenha uma outra máquina,
que seja
; servidor de arquivos e de páginas html. Claro que você vai ter que indicar o nome dela
até
; sob sua autoridade (SOA) ela é a máquina wwwfserv.eeviac.com.br. Ela na verdade será
sempre
; envocada quando suas páginas Internet serão chamadas, ou quando alguém for se
conectar
; via FTP nela, então você cria os apelidos www e ftp para a sua wwwfserv, ou seja, agora
sempre
host3 IN A 200.230.200.3
; Bom, agora sim você continua dando seus nomes à suas máquinas. O Nome que você
; quiser, por isso os exemplos abaixo não seguem um padrão. Para demonstrar que pode
ser
; o nome que você bem entender. Claro que deve-se considerar uma opção de organização
; Se outros servidores existissem, como o nosso exemplo wwwfserv, o nome teria que ser
; configurado, claro...
maq4 IN A 200.230.200.4
; Agora em todas essas entradas estamos adminindo que seja de simples hosts da
maq5 IN A 200.230.200.5
; Se por exemplo a máquina 6 fosse do presidente da sua empresa, ela poderia Ter
ma7 IN A 200.230.200.7
; Faça como quiser, da melhor forma para a organização e agilidade da sua empresa,
escola,
; provedor internet...
eeviac8 IN A 200.230.200.8
xffa IN A 200.230.200.9
; e que o nome será sempre sob a sua zona (SOA), ou seja, no próximo caso...
corduroy IN A 200.230.200.11
eev12 IN A 200.230.200.12
eevbr13 IN A 200.230.200.13
|| || || || || || ||
|| || || || || || ||
Agora o nosso servidor de nomes já está quase perfeito. Ele já pode responder com total
autoridade pelos nomes dos hosts da nossa zona (domínio/rede) e ao fazermos uma
consulta ao nosso servidor de nomes, ele pode identificar e servir informações que
permita qualquer outra máquina ou rede na internet identificar o endereço IP dos nomes
dos nossos hosts. Sendo assim, se alguém quiser saber qual o endereço IP por exemplo,
da máquina xffa.eeviac.com.br assim que o nosso servidor de nomes for interrogado,
então a resposta (200.230.200.9) será imediatamente exibida. Estamos quase prontos...
5.5.5 /usr/named/db.200.230.200
Vamos dar uma olhada no formato que esse arquivo deve ter:
$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
1 IN PTR rt.eeviac.com.br.
2 IN PTR ras.eeviac.com.br.
10 IN PTR eeviacbsd.eeviac.com.br.
10 IN PTR pop3.eeviac.com.br.
10 IN PTR smtp.eeviac.com.br.
10 IN PTR ftp.eeviac.com.br.
10 IN PTR www.eeviac.com.br.
9 IN PTR xffa.eeviac.com.br.
3 IN PTR eev3.eeviac.com.br.
4 IN PTR eev4.eeviac.com.br.
5 IN PTR eev5.eeviac.com.br.
6 IN PTR eev6.eeviac.com.br.
7 IN PTR eev7.eeviac.com.br.
8 IN PTR eev8.eeviac.com.br.
11 IN PTR freebsd.eeviac.com.br.
12 IN PTR eev12.eeviac.com.br.
13 IN PTR eev13.eeviac.com.br.
14 IN PTR eev14.eeviac.com.br.
15 IN PTR eev15.eeviac.com.br.
16 IN PTR eev16.eeviac.com.br.
17 IN PTR eev17.eeviac.com.br.
18 IN PTR eev18.eeviac.com.br.
19 IN PTR eev19.eeviac.com.br.
A descrição dos endereços IPs podem ser completos, mas não tem porque conter a rede,
se no named.conf nós declaramos que trataremos da rede 200.230.200.in-addr.arpa, o
servidor de nomes já sabe exatamente de que rede estamos tratando. Agora a ação
reversa indica para o nosso servidor de nomes que, para o cliente (host) número X da
nossa rede, nós estamos adicionando uma entrada (IN) que aponta (PTR) para o nome da
máquina. Vamos analisar com mais detalhes então esse arquivo:
$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
1 IN PTR rt.eeviac.com.br.
2 IN PTR ras.eeviac.com.br.
10 IN PTR eeviacbsd.eeviac.com.br.
10 IN PTR pop3.eeviac.com.br.
10 IN PTR smtp.eeviac.com.br.
10 IN PTR ftp.eeviac.com.br.
10 IN PTR www.eeviac.com.br.
; uma entrada reversa para cada nome que ele deve responder.
9 IN PTR xffa.eeviac.com.br.
3 IN PTR eev3.eeviac.com.br.
4 IN PTR eev4.eeviac.com.br.
5 IN PTR eev5.eeviac.com.br.
6 IN PTR eev6.eeviac.com.br.
7 IN PTR eev7.eeviac.com.br.
8 IN PTR eev8.eeviac.com.br.
11 IN PTR corduroy.eeviac.com.br.
12 IN PTR eev12.eeviac.com.br.
13 IN PTR eev13.eeviac.com.br.
14 IN PTR eev14.eeviac.com.br.
15 IN PTR eev15.eeviac.com.br.
16 IN PTR eev16.eeviac.com.br.
17 IN PTR eev17.eeviac.com.br.
18 IN PTR eev18.eeviac.com.br.
19 IN PTR eev19.eeviac.com.br.
Bom, agora que você já tem todos os arquivos que compõe a configuração do seu
servidor de nomes prontos, então é hora de iniciar o seu servidor de nomes, e cuidar para
que ele se inicie sempre que necessário, junto ao sistema operacional, e com os
parâmetros corretos.
Bom, você já sabe que é o BIND quem faz as requisições ao NS, para obter informações
sobre nomes, e depois retorna essas informações ao cliente que fez esse pedido. Então,
para melhorar sua segurança, você deve garantir que o BIND seja o único que tenha o
direito de fazer essas requisições. Sabe também que o NAMED é o programa mais usado
para essa tarefa. Então você vai ter que avisar ao seu sistema FreeBSD que ele vai ser
servidor de nomes, e que vai usar o NAMED como o programa para tal. Ainda: vai dizer
pro NAMED ser levantado pelo usuário e grupo do usuário BIND. Esses fatos não são
obrigatórios, mas ajudam na segurança do seu servidor.
Lembra-se que no início desse capítulo eu disse que mudava o local dos diretórios onde
os arquivos de base de dados e configuração do servidor de nomes ficava, por segurança,
certo? Bom, vamos lembrar de um detalhe... pra rodar o servidor de nomes, o usuário
deve ser alguém com um pouco mais de direitos no sistema, e isso não é bom. O Usuário
BIND tem alguns privilégios que podem ser perigosos, se alguém mal intencionado puder
usufruir deles de alguma forma.
Felizmente, não é nada fácil se tornar o usuário que roda seu servidor de nomes, e o
que pode ser feito, as vezes (bem raramente...) é algum ser muito esperto conseguir
executar comandos arbitrários no seu sistema, com os direitos do root. Poucos comandos
podem ser executados, e o suposto invasor faz isso quase que às escuras, mas quando se
tem um pouco mais de liberdade, um terceiro pode até abrir uma shell no seu servidor, aí
estamos totalmente à mercê.
E como essa forma de exploitar um servidor BIND é mesmo quase sempre as escuras,
com comandos lançados às cegas, então, é claro que se o invasor conheça menos do seu
sistema, então melhor, porque ele não fica "adivinhando" onde você roda os seus arquivos,
e/ou onde o BIND tem esses direitos a mais. Direcionando um diretório exclusivo aos
arquivos do BIND, você pode usar de formas administrativas no FreeBSD para não
permitir que alguns tipos de ações sejam feitas, ou executadas a partir daquele usuário.
Liberar direitos direcionados é uma forma de previnir problemas com espertinhos que
queiram brincar com seu sistema. Claro que estamos tratando aqui de situações raras,
mas, recentemente uma das versões mais distribuídas do BIND teve um probleminha, e
se tornou alvo desses tipos de exploits. Esse problema foi o bastante para tirar do ar
alguns dos servidores mais bem administrados do mundo, inclusive 3 Root Nameservers
ao mesmo tempo.
Infelizmente fazer isso com o BIND não é tão fácil quanto em relação aos seus usuários
e o acesso FTP deles... Essa é a ação mais segura que se pode fazer, mas poucas pessoas
conseguem ou nem tentam fazer isso... Não vamos falar disso agoura, apenas foi
comentado porque, no início desse capítulo dissemos algo sobre segurança.
Bom, mas vamos voltar ao nosso DNS no FreeBSD. Agora você tem que dizer ao seu
FreeBSD que ele será um servidor de nomes, e tem que dizer que ele vai usar o NAMED
pra isso, e vai também permitir requisições do usuário BIND. Bom, pra isso basta você
adicionar 3 linhas no seu arquivo /etc/rc.conf
A Segunda linha (named_program="named") diz que o Programa que vai ler os serviços
de nomes será o Name Daemon, ou o named. Apesar de existirem outras opções, o
named é o mais indicado.
Ou seja, com essas opções você esta dizendo ao FreeBSD que ele vai ser um servidor de
nomes, e que deve iniciar sempre esse serviço com o comando:
Agoura sim, o seu servidor de nomes está prontinho pra rodar. Para testar, você pode
digitar:
# named.restart
ou
# named.reload
ou
# ndc restart
ou
# named -u bind -b bind -g /etc/namedb/named.conf
#!/bin/sh
/sbin/killall -9 named
/bin/echo -n "Reiniciando servidor de nomes..."
/usr/sbin/named -u bind -g bind -c /etc/namedb/named.conf
/bin/echo " OK!"
Basta criar um script com esse nome e dar permissão de execussão à ele (chmod +x).
Coloca-lo na sua PATH é recomendado.
5.7 NSLOOKUP
Bom, depois de uma explicação tão detalhada, dificilmente você não conseguirá
configurar o seu servidor de nomes (DNS) no FreeBSD. Mas para ter certeza que o seu
servidor de nomes esta funcionando da forma correta, você pode usar uma ferramenta
muito boa. Essa ferramenta se chama nslookup e é usada para interrogar servidores de
nomes. Ela é distribuída juntamente com o software BIND, e faz parte das interfaces
cliente do serviço de nomes.
Para garantir que você estará usando o seu próprio servidor de nomes para se
comunicar com outros servidores, então configure o seu resolver para procurar apenas no
seu próprio servidor de nomes. Edite o seu arquivo /etc/resolv.conf e certifique-se que
existam as entradas DOMAIN, SEARCH, e NAMESERVER configuradas, e que a entrada
NAMESERVER aponte para o seu endereço IP, ou seja, faça com que o seu servidor de
nomes seja você mesmo. Garanta que não exista outra entrada NAMESERVER, assim,
não existindo um servidor de nomes secundário configurado, você garante que, se tudo
der certo é mesmo porque o seu servidor de nomes esta perfeito.
# ee /etc/resolv.conf
e adicione:
domain seudominio.com.br
search seudominio.com.br
nameserver IP do SEU SERVIDOR DE NOMES
domain eeviac.com.br
search eeviac.com.br
nameserver 200.230.200.10
Agora sim, você está pronto para usar o NSLOOKUP para testar o seu servidor de
nomes.
Digite "nslookup" e a saída, se tudo ser certo, deve ser parecida com:
# nslookup
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
>
Então reveja os seus arquivos de configuração do named. Uma dica é, se não funcionar
na sua interface externa de rede (no nosso caso 200.230.200.10) tente colocar nameserver
127.0.0.1 no seu /etc/resolv.conf. Se dessa vez funcionar, então estamos diante de um
problema não muito comum. Para garantir que seja esse o problema, certifique-se que o
seu servidor de nomes esteja ouvindo na interface externa. Para isso, a saída do comando
netstat -an | grep -i list deve apontar o seu IP real (interface externa) ouvindo na porta 53.
Outra forma de certificar isso, é dar telnet na porta 53 da interface externa. (telnet
200.230.200.10 53 - no nosso exemplo). Se a conexão se estabelecer e o nslookup não
funcionar na interface externa, então é o nosso problema raro.
Isso acontece quando o seu reverso não esta configurado corretamente. Se seu reverso
não funcionar da forma certa, o BIND, por segurança, não responde a query nenhuma
feita na interface externa, apenas no loopback. Mesmo ouvindo na interface ele
simplesmente não responde. Esse problema com o reverso pode ser a entrada
xxx.xxx.xxx.in-addr.arpa no seu /etc/namedb/named.conf . Se você está usando BIND
acima do 8.2.4 tente não colocar a zona de abrangência (xxx-xxx) no seu named.conf
Se assim também não funcionar, reveja seus arquivos e reveja os exemplos dessa
documentação porque você deve ter configurado alguma informação imprecisa.
Mas se der certo, você pode ter certeza que o seu servido de nomes está se
comunicando com os outros servidores de nomes do mundo, da seguinte forma: ao digitar
"nslookup", a saída da resposta será uma prompt com um sinal de maior (>):
# nslookup
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
>
Então nessa prompt digite o nome de vários domínios, e também os endereços IP, para
testar os reversos. As saídas devem ser algo parecido com:
# nslookup
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
> www.fatectq.com.br
Non-authoritative answer:
Name: www.fatectq.com.br
Address: 200.210.2.10
> www.vitalogy.org
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
Non-authoritative answer:
Name: www.vitalogy.org
Address: XXX.XXX.XXX.XXX
> 200.230.200.11
Default Server: eeviacbsd.eeviac.com.br
Address: 200.230.200.10
Non-authoritative answer:
Address: 200.230.200.11
Name: corduroy.eeviac.com.br
O nslookup tem uma série de opções de uso, para aprender como usa-las, digite set all
na prompt
>
# nslookup
Default Server: maquina1.eksffa.net
Address: 143.106.10.11
>set all
Veja agora uma peque lista das opções mais comuns do NSLOOPUP e sua descrição:
[no]search A opção search encobre o domínio default (opção defname). Ou seja, a opção
defname somente se aplica se a opção search está desligada. O comando nslookup
acrescenta os nomes dos domínios listados na lista de procura (srchlist) a nomes que não
terminam em "."
[no]d2 O debug no nível 2 é desativado por default. Se ativado, são exibidos os pacotes
enviados em adição à saída do debug.
[no]vc Por default, o comando nslookup utiliza pacotes UDP ao invés de TCP (circuitos
virtuais ou virtual circuits - vc). A maior parte das perguntas (queries) são feitas utilizando
UDP. Da mesma forma que o resolver pode ser instruído a utilizar TCP, o nslookup também
oferece a mesma funcionalidade.
[no]ignoretc Por default, o nslookup não ignora pacotes truncados. Se é recebido um pacote
que possui o bit indicativo de pacote truncado ligado, indicando que o servidor de nomes
não conseguiu incluir toda a informação dentro de um pacote UDP, o nslookup não o ignora.
É repetida a pergunta utilizando-se uma conexão TCP ao invés de UDP.
port=53 O serviço DNS atende na porta 53. O DNS pode ser inicializado em outra porta
para fins de debug e o nslookup pode ser direcionado a utilizar esta nova porta.
class=IN A única classe que importa é IN (Internet). Existem outras classes como por
exemplo HESIOD (HS).
Retry=4 Envia a pergunta 4 vezes antes de desistir. Após cada pergunta o timeout é
dobrado.
root=ns.nic.ddn.mil Existe uma facilidade chamada root que chaveia o servidor de nomes
para o servidor identificado por esta opção.
Domain= Este é o domínio default acrescido ao nome fornecido caso a opção defname
esteja ligada.
Srchlist= Se a opção search estiver ativa, estes são os domínios acrescidos a nomes que
não se encerrem em "."
% nslookup
Default Server: maquina1.eksffa.net
Address: 143.106.10.11
> acme.com
Server: maquina1.eksffa.net
Address: 143.106.10.11
Name: acme.com
Address: 206.86.3.110
> 206.86.3.110
Server: maquina1.eksffa.net
Address: 143.106.10.11
> acme.com
Server: maquina1.eksffa.net
Address: 143.106.10.11
> acme.com
Server: maquina1.eksffa.net
Address: 143.106.10.11
Non-authoritative answer:
> acme.com
Server: maquina1.eksffa.net
Address: 143.106.10.11
>
% nslookup
Address: 143.106.10.54
mit.edu
Server: xffa.eksffa.net
Address: 143.106.10.54
Name: mit.edu
Address: 18.72.2.1
> mit.edu
Server: xffa.eksffa.net
Address: 143.106.10.54
Non-authoritative answer:
Name: mit.edu
Address: 18.72.2.1
>
Se um servidor recebe uma pergunta não recursiva, ele responde ao cliente fornecendo
os registros NS que encontrou. Por outro lado, se a pergunta for recursiva, o servidor
encaminha perguntas aos servidores obtidos a partir dos registros NS que encontrar.
Quando o servidor recebe uma resposta de um dos servidores remotos, ele coloca a
informação no cache e repete o processo, se necessário. A resposta do servidor remoto irá
ou responder a pergunta original ou conterá uma lista de servidores mais embaixo na
hierarquia do espaço de informações do DNS que esteja mais próxima da resposta.
Address: 127.0.0.1
Served by:
- E.ROOT-SERVERS.NET
192.203.230.10
NASA.GOV
- NS.GSFC.NASA.GOV
128.183.10.134
NASA.GOV
- JPL-MIL.JPL.NASA.GOV
128.149.1.101
NASA.GOV
- MX.NSI.NASA.GOV
128.102.18.31
NASA.GOV
> acme.com
Server: ns.nasa.gov
Served by:
- E.ROOT-SERVERS.NET
192.203.230.10
NASA.GOV
- NS.GSFC.NASA.GOV
128.183.10.134
NASA.GOV
- JPL-MIL.JPL.NASA.GOV
128.149.1.101
NASA.GOV
- MX.NSI.NASA.GOV
128.102.18.31
NASA.GOV
Name: acme.com
Served by:
- NS.BEST.COM
204.156.128.1
acme.com
- NS2.BEST.COM
206.86.0.21
acme.com
- NS3.BEST.COM
204.156.128.20
acme.com
Address: 204.156.128.1
> acme.com
Server: ns.best.com
Address: 204.156.128.1
Name: acme.com
Address: 206.86.3.110
O comando nslookup pode também ser utilizado para transferir uma zone inteira
utilizando-se o comando ls. Esta facilidade pode ser utilizada para resolução de
problemas, realizar contagem do número de hosts em determinado domínio, etc.
% nslookup
Address: 143.106.10.11
> ls ad.eksffa.net
[maquina1.eksffa.net]
ad.eksffa.net. 143.106.10.2
ns.ca.eksffa.net. 143.106.32.65
ns.ca.eksffa.net. 143.106.32.129
maquina1.eksffa.net. 143.106.10.11
maquina1.eksffa.net. 143.106.1.5
localhost 127.0.0.1
ftp 143.106.32.67
mail 143.106.32.65
www 143.106.32.126
> ls -t mx cenapad.eksffa.net
[maquina1.eksffa.net]
ad.eksffa.net. 0 ns.ca.eksffa.net
ad.eksffa.net. 5 maquina1.eksffa.net
ftp 0 ns.ca.eksffa.net
ftp 5 maquina1.eksffa.net
mail 0 ns.ca.eksffa.net
mail 5 maquina1.eksffa.net
www 0 ns.ca.eksffa.net
www 5 maquina1.eksffa.net
[maquina1.eksffa.net]
########
O BIND name server, é manipulado através de sinais. A tabela abaixo lista os sinais
suportados pelo BIND e uma descrição resumida de sua função:
HUP - Reinicializa o servidor de nomes. Envie este sinal ao servidor primário após modificar
o arquivo de boot (/etc/namedb/named.conf) ou qualquer dos arquivos de seu banco de
dados. O comando named.reload também pode ser usado.
Esse sub-capítulo pode ser entendido como um bônus do nosso capítulo sobre DNS.
Acontece que, Esse serviço de nomes é um dos mais nobres, senão o mais nobre serviço
realizado por um servidor na Internet. Pode-se com isso até mesmo configurar um
servidor para ter autoridade sobre outros domínios/zonas que não sejam de uma rede ou
máquina privada. São os chamados domínios virtuais. Domínios Virtuais serão tratados
logo mais em um capítulo seguinte.
Por ser um serviço tão importante e tão usual na Internet e em redes em geral, vamos
obter e analisar algumas outras informações e vamos ver situações comuns para
administradores de redes e sistemas de informação via Internet.
itd.umich.edu. IN NS dns.cs.wisc.edu.
Essa linha é bem comum hoje nos logs dos nossos serviços de nomes. Saiba que Lame
delegation ocorre quando, por exemplo, o servidor de nomes X é considerado fonte oficial
de informações para o domínio Y. Ao se perguntar ao servidor X sobre o domínio Y são
retornadas informações não oficiais, ou o servidor X não sabe nada sobre o domínio Y.
Para identificar servidores de nomes nesta condição, utilize o programa nslookup (ou
similar) para interrogar os servidores de nomes um nível acima do servidor suspeito.
Obtenha a lista dos servidores para o domínio desejado e por sua vez questione cada um
dos servidores obtidos e verifique se retornam informações oficiais.
O shell script lamers, escrito por Bryan Beecher faz esta verificação automaticamente.
- Diagnósticos Básicos
dig é abrangente que nslookup, é usado por diversas outras ferramentas. Eu uso ele
para criar meus arquivos de cache local, pra usar em Intranet. Thanx ao Lint por ter me
dado a dica!
Esse subcapítulo desse documento aborda uma das mais importantes e indicadas
precauções de segurança que se pode tomar em relação ao sofware BIND. Vamos
demonstrar aqui, de forma clara e prática, todo o procedimento para colocar o BIND
sendo executado em ambiente CHRootado. O Termo CHRoot significa Modificar a Raiz
(CHange Root). A analogia é simples, o ambiente unix segue uma estrutura de arquivos
em árvores hierárquicas, onde o nível mais baixo (raiz), representada nesse ambiente pelo
"/" pode (de acordo com as permissões do sistema) obter acesso à todos os níveis mais
altos da estrutura de arquivos do computador, portanto, todo o sistema local. Esse
conceito básico de ambiente Unix, portanto, pode ser modificado, criando assim um
ambiente virtual da estrutura raiz.
É por esse mesmo motivo que nós executamos o BIND como usuário não privilegiado,
como visto anteriormente nesse mesmo capítulo. Lembre-se que, manter o seu BIND o
mais atualizado possível é tão importante quanto essas medidas de segurança, visto que
todos os problemas quando descobertos, são rapidamente corrigidos. Utilizar um BIND
inferior à versão 8.2.3 é desaconselhado, por motivos de segurança, especialmente se não
for implementado em ambiente chrootado.
O Primeiro passo para começarmos a implementar o nosso ambiente seguro pro BIND,
é termos em mente que nós queremos executar o servidor de nomes como usuário não
privilegiado, como fizemos anteriormente nesse capítulo. Se você já roda o BIND com um
usuário e grupo específicos, então pode aproveitar esse mesmo usuário existente, para
continuar sendo o responsável pelo processo BIND.
No nosso caso, nós utilizamos o usuário padrão que o BIND cria no nosso FreeBSD, o
usuário bind e o grupo bind. Se por algum motivo você ainda roda o BIND como root, e
não tem um usuário específico pra essa finalidade, pode criar agora (se já não existir) o
usuário e grupo bind. Alguns administradores de sistemas costumam criar o usuário e
grupos named, especialmente os da comunidade Linux. Em termos práticos, é indiferente,
mas vamos assumir o que estamos indicando.
Para criar o usuário e grupo bind você pode utilizar o 'adduser', 'addgroup' ou
adicionar com o 'vipw' a linha referente ao usuário. Lembre-se, no FreeBSD se você
simplesmente alterar, manualmente, os arquivos /etc/passwd e /etc/master.passwd a
Base de Dados de usuários não será atualizada, e portanto essa alteração não terá efeito.
Para criar o usuário bind com o vipw, adicione a seguinte linha no ambiente de edição
que o vipw abre:
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
E para criar o grupo BIND, (você pode faze-lo manualmente, ou até mesmo via
sysinstall) adicione a seguinte linha no arquivo /etc/group:
bind:*:53:
Ao criar o usuário bind, lembre-se de atribuir a ele uma shell não válida, e garanta que
o usuário não tenha uma senha definida, o que o impede de se logar no sistema. Você
pode tomar esses cuidados no momento da inclusão do usuário, ou posteriormente,
utilizando o 'chfn'.
Para isso, digite, logado como super-usuário (Root):
# chfn bind
A saída para esse comando deverá ser parecida com a tela a seguir:
Nesse ambiente, você pode modificar toda a informação de finger para o usuário bind,
usual em ambiente Unix, contudo, no FreeBSD esse comando (assim como o vipw)
atualiza as informações na Base de Dados do sistema, ou seja, as informações assim
modificadas se tornam válidas.
Preste atenção na informação 'Home directory' do usuário bind, apontando para o "/". É
indicado que ao criar o usuário bind, (ou alterar seus dados) você defina "/" como o seu
Home Directory, quando nós formos rodar o processo bind em ambiente CHRootado, visto
que onde quer que seja o seu diretório HOME verdadeiro, ao CHRootarmos, ele será
sempre interpretado como a raiz do sistema ("/").
Você pode também reparar o "*" no lugar da senha, tanto na linha do vipw quando no
ambiente do chfn, como dito, para evitar que o usuário se logue no sistema. Finalmente,
como já recomendado, o usuário deve não ter uma senha válida, no nosso caso, nos
mantemos utilizando a shell que foi criada automaticamente, a shell não válida
/sbin/nologin. Você pode criar qualquer arquivo para ser essa shell não válida, como por
exemplo /bin/false ou /bin/semsenha, onde esse arquivo pode ser até mesmo um script
que, por segurança, por exemplo, ao ser executado envie uma mensagem ao
administrador, avisando que na data e hora atual, o usuário específico tentou se logar no
sistema. Ótimas alternativas de segurança.
O que deve-se deixar claro, é que essas shells devem existir, de verdade, e no ambiente
do CHRoot Jail, mais especificamente. Em alguns sistemas Unix, ao usar o chroot()
também deve existir o arquivo /etc/shells no ambiente CHRootado, apontando a
existência da shell não válida. Como nosso caso é específico BSD Unix, não foi necessário
criar esse arquivo no FreeBSD, nem no OpenBSD. Segundo Diego Linke (GAMK) também
não existe a necessidade no NetBSD.
Bom, com usuário e grupo criados, nós já temos um usuário sem privilégios no sistema,
para ser o usuário responsável pelo processo bind. Agora precisamos criar a nossa
estrutura de arquivos, para servirmos nosso processo de tudo (e tão somente) que ele
precise.
6.3.2 Preparando a estrutura de arquivos para o ambiente em chroot()
Agora sim, vamos ter que criar todo o ambiente HOME para o BIND. Vamos lembrar
que, depois de chrootado, esse ambiente home será interpretado como a raiz do sistema,
para o BIND, ou seja, seu diretório home será mesmo o "/" (raiz) em um ambiente de
CHroot Jail. Com isso em mente, devemos então criar todos os arquivos, e numa estrutura
que atenda as necessidades do BIND, para apenas garantir que todos os arquivos
necessários, e "somente" o que for necessário esteja disponível ao BIND.
É muito importante lembrar que, deve-se ter muita atenção ao criar e alterar os
arquivos indicados. De forma alguma devemos alterar os arquivos principais do sistema, e
sim, somente os arquivos na arvore aprisionada do sistema. Ou seja, quando você for
alterar arquivo /etc/master.passwd do ambiente CHRootado, deve tomar cuidados para
não alterar o mesmo arquivo do sistema, esse tipo de engano pode resultar em sérios
problemas no seu sistema.
Bom, agora para começarmos a preparar essa estrutura de arquivos, vamos considerar
que, o diretório principal para o BIND seja o /usr/named, exatamente como tratamos ao
longo desse capítulo inteiro. Ou seja, o /usr/named é o arquivo onde estarão nossas
informações de zona, zona reversa e nossos db's de zonas pra todos os domínios nos
quais nós teremos autoridade. E agora, aplicando o conceito de chroot enviroment, o nosso
diretório /usr/named será interpretado pelo BIND como sendo o diretório /.
Portanto:
/usr/named ==> /
Então, agora toda a estrutura de arquivos deverá ser criada abaixo desse diretório.
Agora devemos criar o /dev/null, que é um tipo especial de device nula a qual nós já
conhecemos bem.
Depois deveremos criar toda a estrutura usr/ exatamente da forma como o BIND vai
precisar, contendo os diretórios usr/lib/, usr/libexec/, sbin/, usr/share/ com o diretório
zoneinfo/ e zoneinfo/America e usr/sbin/. Finalmente o diretório bin/ caso seja necessário
(necessário no OpenBSD, no FreeBSD não). Depois, mais um diretório, que será utilizado
pelo bind para guardar as informações de log e informações que nós queiramos. Vale
lembrar que na série 9 do BIND, é o administrador que cria as regras e níveis de logging
data. Então vamos assumir esse diretório de informações diversas como o info/.
Para facilitar a vizualização da estrutura que nós precisamos, veja saída do comando
du:
# du -h /usr/named/
1.0K ./dev
11K ./etc/namedb
80K ./etc
1.4M ./usr/lib
2.0K ./usr/share/zoneinfo/America
3.0K ./usr/share/zoneinfo
4.0K ./usr/share
3.9M ./usr/sbin
83K ./usr/libexec
5.4M ./usr
649K ./bin
2.0K ./info
Agora sim, vamos finalmente garatir todos os arquivos que o bind vai precisar para ser
executado em chroot().
A sintaxe para criação desse do dev/null, logado como superusuário (root) deve ser:
# mknod null c mi mj
Assim o mknod interpreta que o null deve ser criado (opcao "c") com os Minor Number
(mi) e Major Number (mj). Para descobrir esses valores, você deve usar o comando "ls -l
/dev/null" então, no lugar do tamanho do arquivo null, serão mostrados, respectivamente
os valores "mi" e "mj" do seu sistema. Agora você pode criar esse arquivo no seu ambiente
de chroot jail com os mesmos valores.
Esses valores, normalmente são 2 e 2 (2=mi e 2=mj). Se no seu FreeBSD esses valores
também forem esses, então basta digitar os comandos:
# cd /usr/named/dev/
# mknod null c 2 2
As informações devem estar exatamente como no sistema, mas deve-se alterar a senha
para "*" para evitar que ambos se loguem no sistema, e apontar a shell para um
interpretador de comandos não válido, como /sbin/nologin.
# ee /usr/named/etc/passwd
Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida.
# ee /usr/named/etc/master.passwd
Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida e alterando sua senha para "*".
As linhas nesse arquivo devem ficar parecidas com as alterações que você deve ter feito,
usando o vipw, como citado no subcapítulo anterior.
Agora o arquivo resolv.conf; Também deve ser copiado do sistema, e não precisa ser
alterado, imaginando-se que seu servidor de nomes já esteja ativo. Se precisar configura-
lo ainda, leia esse capítulo desde o início. Então copiemos:
# cp /etc/resolv.conf /usr/named/etc/
Então, vamos copiar o arquivo group do sistema para o ambiente chrootado, e editar,
para apagar todos os grupos não necessários ao BIND:
# cp /etc/group /usr/named/etc
# ee /usr/named/etc/group
Agora edite o arquivo, com o easy editor, e delete todos os grupos existentes, deixando
apenas o sys e o bind
Então vamos precisar que no nosso ambiente chrootado, esses arquivos também
existam, contudo, com informações apenas dos nossos dois únicos usuários, o root e o
bind.
Para criarmos esses Data Bases de informações dos usuários do sistema, devemos
usar o comando pwd_mkdb; Ele pode criar os arquivos spwd.db e pwd.db em qualquer
diretório, e a partir de qualquer passwd e master.passwd contanto que tenham um
formato válido, interpretável pelo pwd_mkdb.
Portanto, para criar os Data Bases no nosso diretório dentro do ambiente chrootado,
vamos usar o comando, logados como root, da seguinte forma:
A opção "-d" indica ao pwd_mkdb qual o diretório onde os Database Files serão criados,
e o próximo parâmetro indica a partir de qual arquivo essas informações devem ser
criadas.
Pronto, assim você evita que quando for rodar o bind em ambiente chrootado, o
sistema indique o usuário bind como usuário desconhecido.
Para descobrir quais bibliotecas um arquivo binário precisa, você deve usar o comando
ldd.
named
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)
lc_r.5 => /usr/lib/libc_r.so.5 (0x4022a000)
lc.5 => /usr/lib/libc.so.5
Então vamos copiar essas bibliotecas, para o nosso ambiente chrootado, que é onde o
named vai procura-las. Como root, digite:
# cp /usr/lib/libcrypto.so.1 /usr/named/usr/lib/
# cp /usr/lib/libc_r.so.5 /usr/named/usr/lib/libc_r.so.5
# cp /usr/lib/libc.so.5 /usr/named/usr/lib/libc.so.5
Lembre-se, essas bibliotecas com certeza serão outras, de acordo com a versão do seu
sistema operacional, versão do BIND e forma como você o compilou.
No caso da área ser São Paulo (meu caso), então eu vou precisar compiar o arquivo:
/usr/share/zoneinfo/America/Sao_Paulo
Para:
/usr/named/usr/share/zoneinfo/America/Sao_Paulo
Para descobrir onde está o binário named, use o comando: 'whereis named'
E então copie-o para /usr/named/usr/sbin/
Portanto, vamos copiar essa biblioteca pra dentro do ambiente seguro (chroot()
enviroment):
# cp /usr/libexec/ld-elf.so.1 /usr/named/usr/libexec/
Em alguns sistemas operacionais, você vai ter que criar o etc/shells e constar a
existencias dessas shells falsas nesse arquivo. No FreeBSD não foi preciso.
/dev/
null
/etc/namedb/
named.conf
/etc/
group
master.passwd
passwd
pwd.db
resolv.conf
spwd.db
/usr/lib/
libc.so.5
libc_r.so.5
libcrypto.so.1
/usr/share/zoneinfo/America/
Sao_Paulo
/usr/sbin/
named
/usr/libexec/
ld-elf.so.1
/bin/
false
/info/
Vale lembrar que, de acordo com a versão do BIND, você pode precisar criar outros
diretórios e arquivos, mas esses podem ser facilmente descobertos, ao ler os logs de
provaveis erros, no syslogd ou do daemon. No BIND9x é ainda mais fácil, acionando-se a
opção de debug (-g).
Finalmente, vamos colocar o BIND rodando no nosso ambiente aprisionado. Agora que
você já satisfez todas as dependências de estrutura de arquivos e usuário, já podemos
assegurar nosso servidor de nomes.
Para criar um ambiente de CHroot Jail, no FreeBSD você tem o comando chroot, que
utiliza a função chroot() implementada a nível de Kernel. Para aprender como usar esse
comando com mais detalhes, utilize o manual online:
# man chroot
Mas a sintaxe básica para a utilização do chroot com o BIND, deve ser:
No BIND 8x, onde ainda é necessário apontar o grupo, além de usuário, com a
directiva '-g'.
Ou:
No BIND9x, onde apenas o usuário deve ser indicado, e a opção -g habilita o debug-
mode, para se poder analizar erros, e não lança o processo como background.
Mas...
Essas opções são não viaveis em alguns Linux. O Kernel que você costuma encontrar
esse tipo de incapacidade estão listados no manual online do named (man named).
Para iniciar o named lançando-o em ambiente chrootado e com usuário não privilegiado,
devemos então inicia-lo da seguinte forma:
No BIND9x, a opção "-t" (Troggle chroot() directory) é a mesma, contudo apenas a opção
"-u" deve ser usada para definir qual usuário deve ser o dono do processo. Nessa versão
do BIND, a opção "-g" inicia o Debug Mode, e mantém o processo em foreground.
Pronto, agora sim você já deve estar rodando o seu BIND em ambiente seguro. Se algo
der errado, você pode acompanhar pelos logs que você está acostumado, no BIND8, ou
pelo Debug Mode no BIND9, e descobrir qual foi o erro ou o que faltou no seu ambiente
seguro.
Agora, devemos automatizar esse processo, no FreeBSD.
Para isso, vamos editar o arquivo /etc/rc.conf
Nesse arquivo, você deve alterar ou criar (caso não existam) as seguintes linhas:
named_enable="YES"
named_program="/usr/named/usr/sbin/named"
named_flags="-t /usr/named -u bind"
Agora você já avisou como o FreeBSD deve iniciar o named, quando necessário. Caso
você costume fazer alterações constantes no seu servidor de nomes e vai ser duro se
acostumar com ficar digitando "/usr/named/usr/sbin/named" toda vez que você quizer
chamar o processo, crie um symlink (link simbólico) apontando o /usr/sbin/named para
o named do seu ambiente seguro: /usr/sbin/named -> /usr/named/usr/sbin/named ;}
Última dica básica: consideramos que os seus arquivos de zona e de reveso já estivesse
no diretório /usr/named, que é onde eles foram indicados à serem criados ao longo desse
capítulo. Se esse não é o seu caso, copie os arquivos ou crie a estrutura de diretórios do
ambiente chrootado de acordo com a sua preferência.
options {
directory "/";
query-source address * port 53;
};
Em alguns casos, o syslogd não vai mais conseguir logar as ações do bind, devido ao
fato do /dev/log não existir no ambiente chrootado. Como solução, devemos indicar ao
syslogd para criar um unix sock em /dev/log com a opção "-a"; Comando: "syslogd -a
/usr/named", estando logado como root.
Feitas essas ressalvas, você está pronto pra configurar seu próprio ambiente chroot()
para o BIND. Preparados da forma como melhor lhe convier. Se quiser, pode até apagar o
diretório /etc/namedb no sistema, visto que agora você vai usar somente o ambiente
chrootado. Mantenha um BACKUP atualizado sempre.
# cp /usr/libexec/named-xfer /usr/named/usr/libexec/
# ldd /usr/named/usr/libexec/named-xfer
# ldd /usr/libexec/named-xfer
libc.so.4 => /usr/lib/libc.so.4 (0x2809c000)
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)
Outro detalhe, esse um pouco menos banal. Diferente do named, o programa named-
xfer não faz apenas leituras nos nossos arquivos de zona e de reversos. Por ser o servidor
secundário, quando as informações primárias são atualizadas, ele precisa também
atualizar os DB's (databases) de informações secundárias, ou seja, temos então que
garantir permissão de escrita (write) nos arquivos que o servidor de nome terá que
atualizar. Os DB de zonas secundárias. Para isso, garanta os modos 755 para que o dono
dos arquivos (bind) possa ter totais permissões nos arquivos que forem zonas
secundárias:
Feitas essas alterações, você já pode garantir a execussão do seu servidor de nomes
secundário, também em ambiente seguro. Qualquer erro pode facilmente ser descoberto,
analizando-se os logs usuais, os quais você já esta acostumado, e serem corrigidos.
Essas explorações são sempre rapidamente corrigidas, mas não são tão rapidamente
atualizadas pelos administradores de sistemas, visto que a grande maioria não é ligada a
Security Advisories, ou em casos mais comuns, esses administradores tem funções
distintas dentro de uma empresa, e não são somente administradores do sistema,
resultando em uma falta de tempo iminente para cuidar de atualizações e correções de
software.
A forma como o BIND foi escrito até a série 8, é a principal razão dessas explorações.
Agora o BIND foi reescrito, em sua versão 9, e além da tendência a menor exploração e
abuso de seus serviços, o BIND9 incorporou diversas novas características, tanto
relacionadas à segurança do serviço, quanto à eficiência e maiores possibilidades de
configuração no servidor de nomes.
- Segurança no DNS:
DNSSEC (zonas autoritativamente assinadas);
TSIG (transações DNS assinadas) ;
- Views
Um processo do servidor pode diferenciar tipos distintos de "visões" (as views) das
informações de nomes, podendo dividir uma "visão interna" de nomes para alguns clientes,
e outra "visão externa" de nomes para outros clientes.
- Suporte a Multiprocessamento.
- Arquitetura comprovadamente portável.
ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz
ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz.asc
Pro FreeBSD, o binário disponível hoje, é a versão 9.1.3 do BIND, disponível em:
ftp://ftp5.freebsd.org/pub/FreeBSD/ports/i386/packages-4.3-stable/All/bind-
9.1.3rc1.tgz
Esses mesmos arquivos (exceto os binários), assim como as versões mais recentes do
BIND9 também estarão sempre disponíveis no mirror brasileiro da ISC, servido pela pop-
mg.com.br no endereço:
ftp://ftp.pop-mg.com.br/pub/isc/bind9/
Normalmente, você já deve ter a OpenSSL instalada e em uso no seu FreeBSD. Para
instala-la, você pode fazer via PORTS, via pkg_add ou pelo fonte, disponível em
www.openssl.org. Informações sobre como instalar software pelo ports ou com pkg_add
disponíveis nos capítulos anteriores dessa documentação.
Essas são as opções para indicar o caminho da biblioteca OpenSSL e para indicar qual
será o diretório de configuração do BIND9. O padrão para essa última opção, se não
alterada, é /etc/, mas como no FreeBSD o padrão é /etc/namedb e nosso capítulo de
configuração do servidor de nomes e capítulo de Chroot Enviroment tratou do caminho
padrão no FreeBSD, e sendo o FreeBSD nosso sistema operacional For Choice, vamos
optar pelo nosso /etc/namedb/.
# cd bind-9.2xx/
# ./configure --with-openssl=/usr/include/openssl --sysconfdir=/etc/namedb
Agora sim, ao final das verificações e dos ajustes de configuração, o BIND9 já está
pronto pra ser compilado:
# make
Agora você pode acabar a instalação do seu BIND9. Logado como root, digite:
# make install
Pronto, todos os programas já foram compilados e construidos, e estão acima do
diretório bin/ dentro do seu diretório de instalação do bind9. Normalmente parecido com
~/bind-9.xxx/bin/. Você pode copiar os programas ou criar links simbólicos, para onde
quer que você ache necessário, lembrando sempre que é ideal que esses programas
estejam no path do seu interpretador de comandos (shell), assim como as man pages
(páginas de manual online) também, criadas no diretório man/ do BIND9.
O arquivo named.conf é o arquivo que mais ganhou novas opções, exatamente por ser o
arquivo mais importante para o servidor de nomes. Vamos então dar uma ênfase especial
nessas novas mudanças, e entendermos a utilização de todas as novas opções.
Domínio: eeviac.com.br
Servidor Primário: eeviacbsd.eeviac.com.br
Servidor Secundário: xffa.eeviac.com.br
Segundo Secundário: corduroy.eeviac.com.br
Faixa de IPs da Rede: 200.230.200.0 até 200.230.200.63
Portanto Máscara: 255.255.255.192
- Key: Especifica uma chave, para ser usada nas Autenticações e Autorizações,
quando estivermos usando TSIG
- Logging: Especifica que tipo de informação o servidor de nomes deve logar, e
para onde essas informações (e de que forma) devem ser logadas.
Por padrão, o BIND9 já traz algumas ACLs built-in, para facilitar o uso. São elas:
- any: Absolutamente todas as máquinas (hosts) de todas as redes;
- none: Nenhuma máquina (hosts) de nenhuma rede (net).
- localhosts: Todos os endereços IPs atribuídos às interfaces locais. Por
exemplo, interface de loopback lo0: 127.0.0.1; Interface ethernet xl0(placa de rede):
200.230.200.10 (exemplo).
- localnets: Toda a rede, a qual a máquia faz parte. Definida pelo endereço
atribuído a ela, e pelo endereço de broadcast ou máscara de subrede, no sistema
operacional.
acl internas {
192.168.0.0/24;
192.168.1.0/24;
192.168.2.0/24;
};
Nesse exemplo, nós criamos a ACL chamada internas, fazendo referência a nossas
redes internas. Definimos que internas agora quer dizer nossas 3 redes de intranet.
Sempre que o BIND9 se deparar com a palavra de controle 'internas', ele vai saber que
estamos falando dessas 3 redes definidas acima. Máscara /24 indica 24 bits, ou seja, a
rede inteira.
acl secundarios {
200.230.200.9/32;
200.230.200.11/32;
};
Agora definimos que, sempre que dissermos secundários, o BIND deve interpretar como
sendo nossos servidores secundários, os dois endereços IPs que fazem parte da nossa
ACL. A máscara indica 32 bits, ou seja, é um host único.
acl nonsenseisp {
200.205.2.0/24;
200.205.3.0/24;
};
Essa ACL define que as duas redes (24 bits) nessa definição, devem ser compreendidas
sempre que mencionarmos a a expressão nonsenseisp. Caso você encontre algum ISP que
sempre mantém problemas como lamme delegations ou qualquer outra má configuração
nonsense ;}
Lembre-se que, os nomes para as ACLs e o conteúdo das mesmas são definidos
exclusivamente por você, nonsenseisp por exemplos é um tipo de expressão que não quer
dizer muita coisa, e deve ser compreendido apelas pelo administrador que criou essa ACL.
controls {
inet ( ip_addr | * ) ( port 'ip_port' ) allow endereços_permitidos
keys lista_de_chaves_permitidas;
inet [...];
};
Nos endereços permitidos, pode ser especificada uma ACL previamente declarada.
Vejamos o exemplo a seguir:
controls {
inet 200.230.200.10
allow {
localhost;
internas;
}
keys {
chaves_rndc;
chaves_privadas;
}
};
Com essa regra, abrimos um canal de controle, na porta padrão (953) da interface
externa do servidor (endereço IP 200.230.200.10) e demos permissões para acesso nesse
canal de controle para localhost e para internas onde a segunda é uma ACL previamente
declarada no nosso arquivo de configurações. Definimos também duas chaves, as
chaves_rndc e chaves_privadas para serem as nossas atribuições de assinatura digital,
pra segurança das transações DNS.
As chaves usadas foram previamente criadas. Veja Instrução Keys. A sintaxe de canais
de controle não é mais compativel com as implementadas na série 8 do BIND.
A instrução keys é usada para se criar assinaturas digitais durante as transações DNS,
ou seja, é a característica principal da nova função 'TSIG' do BIND9. A declaração dessa
chave é definida por um nome de chave, chamado também de key_id, seguido de um tipo
de algorítmo a ser seguido, e finalmente a chave, propriamente dita. Atualmente apenas o
algorítmo hmac-md5 é suportado para a autenticação TSIG.
key key_id {
algorithm algorítmo;
secret chave;
};
key servidores-externos {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};
Foi criada então, uma chave de assinatura digital, com o nome servidores-externos. A
utilização dessa chave deve ser feita junto da instrução server, no arquivo de configuração
do BIND. Você vai ver mais detalhes na seção que aborda as Assinaturas de Transações
(Transaction SIGnatures, TSIGs) a seguir.
A sintaxe é simples:
include arquivo;
include servidores-externos.key;
Essa é uma das mais importantes e funcionais novidades do BIND9. Nessa nova versão,
as definições de logs apenas passam a funcionar quando o parsing de toda a declaração
das regras de logs são lidas, ou seja, apenas quando o BIND termina de ler as instruções
de logging é que o log começa a ser gravado. Até isso acontecer, as mensagens são
enviadas normalmente ao daemon de logs do sistema. Em casos extremos, para se
solucionar problemas deve-se usar a opção "-g" para iniciar o BIND. Essa opção inicia o
named em foreground e com o nível alto de debug para a saída de informações.
São utilizadas duas especificações de chamadas junto à instrução logging. Elas são
chamadas de "channel" e de "category".
logging {
channel {};
category{};
};
logging {
channel "nome_do_canal" {
file "path(caminho)";
versions número_específico OU unlimited};
size tamanho;
syslog opção_syslog;
null;
print-category yes|no;
print-severity yes|no;
print-time yes|no;
};
category nome_da_categoria {
nome_do_canal1;
nome_do_canal2;
nome_do_canalX;
...
};
};
Todas as espeficicações de logs tem sua saída definida em um ou mais canais de log,
chamados de channels. Você pode criar quantos canais quizer, para separar suas
definições de logs. Você vai indicar onde os logs serão armazenados, e de que forma, se
em forma de arquivo comum, ou um log criado por um daemon específico para isso. Ao
usar o Syslog a opção "local3" é comumente atribúida para informar o BIND da utilização
do daemon. Você vai também indicar o nível de informação que será logada, utilizando a
opção severity. Quando um nível não é aplicado, o padrão é a utilização do nível info.
A especificação file indica ao BIND para gravar todas as informações de acordo com o
nível definido no severity em um arquivo de texto, especificado no caminho dado. Em
ambientes seguros, utilizando ambiente chrootado, é recomendado uma definição
parecida com file info/tipo_de_log.log como foi tratado no nosso capítulo anterior. Esse
tipo de arquivo ainda pode ser controlado, pelo BIND, controlando que tamanho máximo
esse arquivo pode alcançar, e quantas versões do mesmo poderão existir. A opção size
define o tamanho máximo que esse arquivo vai ter. E a opção versions define quantos
arquivos de logs poderão automaticamente ser criados. Por exemplo, se você definir
versions 2; vão sempre existir os arquivos arquivo.log e arquivo.log.0 balanceados com o
tamanho especificado em size.
Se você espeficiar syslog como destino dos logs, então o sistema vai usar o syslogd
para prover todos os logs necessários, conforme especificados por severity. Contudo, é
requerido uma opção_do_syslog que define a forma como o syslogd vai logar essas
informações. A opção normalmente usada é a "local3". Para conhecer as outras opções
existentes, leia a man-page do syslogd (comando man syslog) ou os cometários no seu
arquivo "/etc/syslog.conf".
A opção severity indica um nível de "prioridade" que definirá os tipos de informações
que serão lançadas como saída de log pelo BIND. Os níveis de prioridade existentes são:
critical | error | warning | notice | info | debug (nível) | dynamic que só pelo nome já dão
uma noção correta do tipo de informações que são logadas. A prioridade debug inicia o
servidor de nomes com a opção "-d <número inteiro>" onde o <número inteiro> em
questão é o nível de debug. Essa opção é diferente da opção "-g", especialmente por definir
um nível de informação e por não manter o processo em foreground. Já a opção dynamic
utiliza a nível de syslog as prioridades que já estão sendo usadas pelo sistema.
São as categorias de logging do BIND9. A utilização dessa categoria pode ser feita de
duas formas, a primeira é utilizar categorias como agrupamentos de canais de logs. Dessa
forma, você pode criar um nome para uma categoria, e dizer que aquela categoria conterá
as informações dos vários canais de logs que você criou com a função channel{}; e usar
essa definição posteriormente.
- default: é a definição de categoria padrão, que é utilizada quando não são definidas
categorias para um canal de log. É similar ao local3 do syslogd em níveis generalizados de
informações.
- database: são informações referentes as dbs internas, utilizadas pelo named para
controlar a autoridade sobre zonas, reversos e dados de cacheamento.
Agora já sabemos como definir nossos canais de logging e quais tipos de categoria
podemos usar para definir os níveis de informações à serem logadas. Veja agora um
exemplo de configuração básica utilizando a instrução logging:
logging {
channel "named_log" {
file "info/named.logs";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel "named_erro" {
syslog local3;
severity error;
print-category yes;
print-severity yes;
print-time yes;
};
category "security" {
"named_log";
"named_erro";
};
category "xfer-out" {
"named_log";
};
category "xfer-in" {
"named_log";
};
};
Foram criados então, dois canais de logging, um canal de logs gerais, chamado
named_log e um canal de logs específico para armazenarmos informações de erros, o
named_erro. No canal de logs mandamos gravar as informações em um arquivo,
localizado no caminho "info/named.logs" e no canal de erros, mandamos logar com o
daemon syslod. Definimos as prioridades de informações com severity nos dois canais, de
mandamos logar as informações definidas pela categoria, pela prioridade e a hora em
questão, com as opções print. Depois definimos as categorias, atribuindo uma a uma ao
canal que nós criamos.
Outra novidade, a opção named-xfer ainda existe, no BIND9, mas ela se tornou
obsoleta e não usável, já que o novo bind incorpora essa função automaticamente em seu
servidor. Portanto o programa named-xfer não é mais necessário para os servidores de
nomes secundários. A opção notify por exemplo, avisa quando uma zona autoritativa foi
modifcada, e está pronta pra transferência ou atualização.
options {
directory "/";
allow-transfer { 200.230.200.9; };
allow-recursion { 200.230.200.0/24; };
statistics-file "/info/named.stats";
dump-file "/info/dump.db";
pid-file "/info/named.pid";
version "Versao Indisponivel";
listen-on port 53 { 200.230.200.10; };
query-source address 200.230.200.10 port 53;
transfer-source 200.230.200.9 port 53;
auth-nxdomain no;
};
Onde "secundarios" é uma ACL que define quais são nossos servidores slaves.
A opção pid-file indica onde o BIND deve criar seu arquivo de texto com o número de
Process IDentification.
Com essas opções você já pode colocar o seu servidor de nomes no ar, rodando com
traquilidade. Lembre-se de usar ACLs sempre que possível, porque ajudam na
administração e consequente segurança do servidor de nomes.
server endereço_ip {
bogus yes|no;
provide-ixfer yes|no;
request-xfer yes|no;
transfers número;
};
A opção bogus da instrução server define um tipo de servidor que possivelmente está
dando informações errôneas sobre zonas e nomes. A palavra bogus pode ser livremente
traduzida como "bobo". Se um servidor for definido como bogus as informações providas
por eles serão consideradas com um nível mais baixo de prioridade. A padrão para essa
opção é "no". Até a data atual essa opção não havia sido implementada no BIND9.
A opção request-ixfer define que o servidor local vai estar agindo como servidor de
nomes secundário, e que vai tratar o servidor especificado na opção server como o
primário. Ao tentar atualizar suas zonas secundárias, ele sempre tentará que essas
requisições dejam incrementais, caso esteja definida opção yes. Se não especificada, essa
opção também assume o resultado global definido em options{};
A opção key é usada para definir um nome de chave, o key_id definido por uma
instrução key, para garantir transação segura quando dois servidores estiverem se
comunicando.
Cada instrução view permite a divisão das informações que o servidor de nome irá
responder, diferenciando pelos endereços IPs, que tipo de resposta cada cliente deverá ter.
Vale lembrar que a ordem das definições de views é importante, já que a resposta será
dada de acordo com a primeira cláusula view onde o endereço IP do cliente for
reconhecido.
view nome_da_view {
match-clientes { lista_de_endereços };
conjunto_de_opções_da_view;
opção_de_zona;
};
As zonas definidas dentro de uma view, serão apenas vistas pelos clientes que tiverem
seu endereço reconhecido pela lista de acessos dessa view. As opções de view
(conjunto_de_opções_da_view) podem ser definidas quase em sua maioria, com as mesmas
instruções existentes na opção options{};. Quando não definidas, as opções globais
definidas em options{}; serão utilizadas.
Como uma zona comum de nomes, é necessário ter uma opção HINT para as zonas
definidas dentro de uma view. Se a opção "IN" for assumida como a classe da zona,
dentro da view, então uma HINT não precisa ser especificada, porque as classes 'IN' as
tem pré-configurada.
view "internet" IN {
match-clients { any; };
zone-statistics yes;
recursion no;
zone "eeviac.com.br" {
type master;
file "db.eeviac.externo";
};
};
view "intranet" IN {
match-clients { 192.168.1.0/24; };
zone-statistics yes;
recursion no;
zone "eeviac.com.br" {
type master;
file "db.eeviac.interno";
};
};
Agora, nessas duas views nós definimos visões distintas para a mesma rede, de acordo
com os clientes. Fizemos um DNS Spliting com um mesmo servidor de nomes, e
separamos as informações que apenas a nossa intranet pode ter acesso, das informações
que toda a internet pode ter.
Usando a opção match-clients definimos quem pode ter acesso a qual zona (zone file)
definida com a instrução zone {}; que será explanada à seguir. Definimos opções de zona
estática e de recurssão. Note que, na primeira view foi usada uma ACL padrão, ou seja,
você pode fazer uso de ACLs que você criar para definir os acessos às views.
Os arquivos de zonas são os mais importantes no servidor de nomes. São eles que
conterão as informações que o seu servidor de nomes deve responder. Esses arquivos de
Zone foram explicados em detalhes no Capítulo 5. No BIND9, esse arquivo ganhou
algumas características a mais que devem ser notadas. O número serial nos arquivos de
zonas agora devem ser do tipo "integer" ou seja, números inteiros. A cláusula $TTL (Time
to Live) se tornou obrigatória no cabeçalho de todos os arquivos de zonas.
As zonas podem ser definidas por classes, se não houver essa definição, por padrão o
servidor de nomes assumirá a classe "IN" indicando que essa é uma zona comum à
Internet. A zona CHAOS criada em 1970 pelo MIT também está implementada, assim
como a zona HESIOD (ou apenas HS), também criada pelo MIT para compartilhar
informações de usuários, grupos, impressoras, etc...
A zona do tipo HINT que define os Root NameServers (".") são obrigatórias na definição
do arquivo de configuração do BIND. A sintaxe de definição de uma zona dentro do
arquivo named.conf permanece igual. O conteúdo da zona agora assume novas
características, como informações "A6" para definição de endereçamento IPv6. Para
maiores informações sobre essas novas opções existentes, veja o manual online: man
named, man bind.
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "eeviac.com.br"{
type master;
file "db.eeviac";
$TTL 14400
@ IN SOA eeviac.com.br. root.eeviac.com.br. (
2000041003 ; serial
28800 ; refresh
14400 ; retry
3600000 ; expire
86400 ; default_ttl
)
@ IN NS eeviacbsd.eeviac.com.br.
@ IN NS ns.embratel.net.br.
@ IN NS xffa.eeviac.com.br.
@ IN MX 10 smtp.eeviac.com.br.
@ IN MX 20 xffa.eeviac.com.br.
@ IN A 200.230.200.10
rt IN A 200.230.200.1
ras IN A 200.230.200.2
Lembrando que as entradas "A" podem ser substituídas por "A6" se formos definir
endereçamento IPv6, e "DNAME" para delegar endereçamento reverso IPv6 de nomes.
Esse processo local se chama Resolver Daemon (lwresd). Por padrão, as aplicações que
fazem uso da biblioteca lwres pra resolução de nomes, farão uma conexão UDP comum,
na porta 921 do endereço de loopback IPv4 (127.0.0.1), e é onde esse servidor de
resolução deve estar ouvindo. Essa definição de endereço e porta pode ser modificada,
usando a directiva "lwserver" no arquivo de configuração do resolver do sistema, o
"/etc/resolv.conf".
Uma configuração mais profunda do lwresd pode ser feita utilizando um arquivo de
configurações similar ao named.conf contendo os mesmos tipos de informações,
declaradas da mesma forma, porém com nome de "/etc/lwresd.conf". Para
implementações futuras e práticas, o servidor de nomes (named) também pode ser
configurado para agir como um daemon lwres, utilizando o parâmetro lwres no arquivo de
configurações named.conf, o que torna essa nova característica realmente funcional.
lwres {
listen-on { lista_de_endereço/lista_ACL };
view nome_da_view;
ndots número;
};
A partir disso, o named vai passar a agir como um lowresd, na porta 53, do endereço
de loopback (127.0.0.1) ou na porta e endereço especificados na directiva listen-on{}; Pode
ser utilizado também as views da mesma forma como foram descritas anteriormente. Se
não houver uma view especificada, a view padrão é utilizada. As directivas "search" e
"ndots" tem a mesma função de quando utilizadas dentro do arquivo "/etc/resolv.conf".
- rndc stop: para o servidor de nomes, contudo, antes ele garante que alguma
tarefa em andamento (como transferências IXFR) sejam concluídas.
O utilitário de administração rndc ainda pode ter várias outras funções futuramente
implementadas, em novas versões, de acordo com as necessidades. A utilização desse
aplicativo requer obrigatoriamente um arquivo de configuração, chamado de
/etc/rndc.conf.
Esse arquivo de configuração é necessário, porque toda a trasação administrativa feita
com o rndc é digitalmente assinada, e uma key de segurança é utilizada para autenticar
essas transações. Um arquivo de configuração pode ser chamado em local alternativo,
utilizando a opção "-c" do rndc.
key chave_rndc {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};
options {
default-server localhost;
default-key chave_rndc;
};
Mas para que essa opção funcione, o servidor de nomes em questão (no caso 'localhost')
deveria ter uma regra de controle, permitindo essa conexão, e compartilhando uma chave
de assinatura digital idêntica no seu named.conf:
key chave_rndc {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};
controls {
keys { chave_rndc; };
};
Agora sim, qualquer comando deferido com o programa rndc estabilizaria uma conexão
digitalmente assinada na porta 953 da máquina local, e efetuaria a transação ordenada.
Existem algumas formas de se gerar uma chave secreta de comunicação entre duas
máquinas, contudo, é importante que se satisfaçam duas dependências. A primeira, é
óbvio, deve ser que as chaves conhecidas em ambas as pontas sejam idênticas, e a
segunda, que essas chaves sejam tratadas pelo mesmo nome. Portanto devemos definir
um nome e um segredo para criarmos uma chave secreta de autenticação.
A geração dos segredos compartilhados entre as chaves podem ser efetuados de duas
formas. A primeira é automatica, e a segunda, manual.
AUTOMATICA:
Para gerar uma chave de forma automática, com 16 bytes (128 bits) e algorítmo hmac-
md5, você pode por exemplo utilizar o comando:
MANUAL:
Para gerar uma chave de forma manual, você precisa apenas cumprir algumas
dependências. Basta saber que uma chave é apenas um conjunto randômico de
caracteres ascii, de base-64. A maioria dos caracteres ascii, contanto que não se inclua
caracteres especiais, são base-64, e portanto são caracteres válidos. O tamanho da chave
deve ter um número de caracteres múltiplo de 4. Portanto qualquer sequência de
caracteres ascii não especiais, com tamanho múltiplo de 4 é uma chave de segurança
válida. Ex: "IhQIU=ihIL-HLAui" é uma key válida.
Como ja dito, a chave deve ser conhecida por ambos os servidores que se comunicarão.
A chave deve ser definida com a opção key já descrita anteriormente, no arquivo
named.conf do servidor. Portanto é recomendado que esse arquivo não possa ser lido por
todos os usuários do sistema, apenas ao dono do processo (modo: 'chmod 700' ou
necessário), ou ainda que a chave esteja anunciada em um arquivo separado, com modos
de permissões seguros no sistema, e que pode ser chamado pelo arquivo named.conf com
a opção include.
Para instruir o servidor a utilizar aquela chave, deve-se usar a opção server{}; também
já descrita anteriormente. Existem ainda as opções de permissão para determinada
função à ser implementada. Essas opções são:
allow-query{};
allow-transfer{};
allow-update{};
Elas devem ser utilizadas no named.conf para definir regras de controle específicas
para as transações. São como ACLs do sistema, mas referente à comunicação baseada em
chaves. Por exemplo:
Essa definição portanto permite que sejam realizadas "Dynamic Updates" (atualizações
dinâmicas) apenas entre os hosts que tenham a chave "chave_master_slave" em comum.
Basicamente, cria-se uma chave para a zona que se quer autenticar, e se especifica a
chave (de extensão .key) com a opção "$INCLUDE" no arquivo da zona que se quer
autenticar. Na prática, o BIND9 oferece várias ferramentas para a criação dessas chaves,
e para assinatura de zonas.
O programa dnssec-signzone assina a zona específica e cria uma zona assinada que
deve ser chamada pelo arquivo named.conf. A sintaxe dos comandos pode ser facilmente
assimilada, lendo-se as páginas de manuais dos mesmos. DNSSEC ainda não está
completamente implementado no BIND9, portanto possíveis modificações ocorrerão nas
próximas versões.
7.9 Leitura Recomendada;
Outras informações, e algum detalhe que por ventura não tenha sido considerado aqui,
pode ser encontrado no diretório "doc/arm/" em formatos DocBook XML e HTML
distribuído junto ao fonte do BIND9 nos endereços citados no início do capítulo.
Excluindo DNS Security (DNSSEC), toda informação aqui tratada foi implementada de
forma prática antes de ser documentada, em dois servidores distintos, o servidor principal
de internet da Faculdade de Tecnologia de Taquaritinga, e o servidor primário do provedor
de serviços internet (ISP) Mac3, de Ibitinga.
Espero que esse documento auxilie o leitor e supra suas necessidades básicas.
Dúvidas que não surgiram durante o curso, serão respondidas à medida do possível,
desde que a leitura dos capítulos prévios sejam consideradas. Estou disponível para
ajudar no que for possível: eksffa@fatectq.com.br
Esse subcapítulo desse documento aborda uma das mais importantes e indicadas
precauções de segurança que se pode tomar em relação ao sofware BIND. Vamos
demonstrar aqui, de forma clara e prática, todo o procedimento para colocar o BIND
sendo executado em ambiente CHRootado. O Termo CHRoot significa Modificar a Raiz
(CHange Root). A analogia é simples, o ambiente unix segue uma estrutura de arquivos
em árvores hierárquicas, onde o nível mais baixo (raiz), representada nesse ambiente pelo
"/" pode (de acordo com as permissões do sistema) obter acesso à todos os níveis mais
altos da estrutura de arquivos do computador, portanto, todo o sistema local. Esse
conceito básico de ambiente Unix, portanto, pode ser modificado, criando assim um
ambiente virtual da estrutura raiz.
É por esse mesmo motivo que nós executamos o BIND como usuário não privilegiado,
como visto anteriormente nesse mesmo capítulo. Lembre-se que, manter o seu BIND o
mais atualizado possível é tão importante quanto essas medidas de segurança, visto que
todos os problemas quando descobertos, são rapidamente corrigidos. Utilizar um BIND
inferior à versão 8.2.3 é desaconselhado, por motivos de segurança, especialmente se não
for implementado em ambiente chrootado.
O Primeiro passo para começarmos a implementar o nosso ambiente seguro pro BIND,
é termos em mente que nós queremos executar o servidor de nomes como usuário não
privilegiado, como fizemos anteriormente nesse capítulo. Se você já roda o BIND com um
usuário e grupo específicos, então pode aproveitar esse mesmo usuário existente, para
continuar sendo o responsável pelo processo BIND.
No nosso caso, nós utilizamos o usuário padrão que o BIND cria no nosso FreeBSD, o
usuário bind e o grupo bind. Se por algum motivo você ainda roda o BIND como root, e
não tem um usuário específico pra essa finalidade, pode criar agora (se já não existir) o
usuário e grupo bind. Alguns administradores de sistemas costumam criar o usuário e
grupos named, especialmente os da comunidade Linux. Em termos práticos, é indiferente,
mas vamos assumir o que estamos indicando.
Para criar o usuário e grupo bind você pode utilizar o 'adduser', 'addgroup' ou
adicionar com o 'vipw' a linha referente ao usuário. Lembre-se, no FreeBSD se você
simplesmente alterar, manualmente, os arquivos /etc/passwd e /etc/master.passwd a
Base de Dados de usuários não será atualizada, e portanto essa alteração não terá efeito.
Para criar o usuário bind com o vipw, adicione a seguinte linha no ambiente de edição
que o vipw abre:
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
E para criar o grupo BIND, (você pode faze-lo manualmente, ou até mesmo via
sysinstall) adicione a seguinte linha no arquivo /etc/group:
bind:*:53:
Ao criar o usuário bind, lembre-se de atribuir a ele uma shell não válida, e garanta que
o usuário não tenha uma senha definida, o que o impede de se logar no sistema. Você
pode tomar esses cuidados no momento da inclusão do usuário, ou posteriormente,
utilizando o 'chfn'.
# chfn bind
A saída para esse comando deverá ser parecida com a tela a seguir:
Nesse ambiente, você pode modificar toda a informação de finger para o usuário bind,
usual em ambiente Unix, contudo, no FreeBSD esse comando (assim como o vipw)
atualiza as informações na Base de Dados do sistema, ou seja, as informações assim
modificadas se tornam válidas.
Preste atenção na informação 'Home directory' do usuário bind, apontando para o "/". É
indicado que ao criar o usuário bind, (ou alterar seus dados) você defina "/" como o seu
Home Directory, quando nós formos rodar o processo bind em ambiente CHRootado, visto
que onde quer que seja o seu diretório HOME verdadeiro, ao CHRootarmos, ele será
sempre interpretado como a raiz do sistema ("/").
Você pode também reparar o "*" no lugar da senha, tanto na linha do vipw quando no
ambiente do chfn, como dito, para evitar que o usuário se logue no sistema. Finalmente,
como já recomendado, o usuário deve não ter uma senha válida, no nosso caso, nos
mantemos utilizando a shell que foi criada automaticamente, a shell não válida
/sbin/nologin. Você pode criar qualquer arquivo para ser essa shell não válida, como por
exemplo /bin/false ou /bin/semsenha, onde esse arquivo pode ser até mesmo um script
que, por segurança, por exemplo, ao ser executado envie uma mensagem ao
administrador, avisando que na data e hora atual, o usuário específico tentou se logar no
sistema. Ótimas alternativas de segurança.
O que deve-se deixar claro, é que essas shells devem existir, de verdade, e no ambiente
do CHRoot Jail, mais especificamente. Em alguns sistemas Unix, ao usar o chroot()
também deve existir o arquivo /etc/shells no ambiente CHRootado, apontando a
existência da shell não válida. Como nosso caso é específico BSD Unix, não foi necessário
criar esse arquivo no FreeBSD, nem no OpenBSD. Segundo Diego Linke (GAMK) também
não existe a necessidade no NetBSD.
Bom, com usuário e grupo criados, nós já temos um usuário sem privilégios no sistema,
para ser o usuário responsável pelo processo bind. Agora precisamos criar a nossa
estrutura de arquivos, para servirmos nosso processo de tudo (e tão somente) que ele
precise.
Agora sim, vamos ter que criar todo o ambiente HOME para o BIND. Vamos lembrar
que, depois de chrootado, esse ambiente home será interpretado como a raiz do sistema,
para o BIND, ou seja, seu diretório home será mesmo o "/" (raiz) em um ambiente de
CHroot Jail. Com isso em mente, devemos então criar todos os arquivos, e numa estrutura
que atenda as necessidades do BIND, para apenas garantir que todos os arquivos
necessários, e "somente" o que for necessário esteja disponível ao BIND.
É muito importante lembrar que, deve-se ter muita atenção ao criar e alterar os
arquivos indicados. De forma alguma devemos alterar os arquivos principais do sistema, e
sim, somente os arquivos na arvore aprisionada do sistema. Ou seja, quando você for
alterar arquivo /etc/master.passwd do ambiente CHRootado, deve tomar cuidados para
não alterar o mesmo arquivo do sistema, esse tipo de engano pode resultar em sérios
problemas no seu sistema.
Bom, agora para começarmos a preparar essa estrutura de arquivos, vamos considerar
que, o diretório principal para o BIND seja o /usr/named, exatamente como tratamos ao
longo desse capítulo inteiro. Ou seja, o /usr/named é o arquivo onde estarão nossas
informações de zona, zona reversa e nossos db's de zonas pra todos os domínios nos
quais nós teremos autoridade. E agora, aplicando o conceito de chroot enviroment, o nosso
diretório /usr/named será interpretado pelo BIND como sendo o diretório /.
Portanto:
/usr/named ==> /
Então, agora toda a estrutura de arquivos deverá ser criada abaixo desse diretório.
Depois deveremos criar toda a estrutura usr/ exatamente da forma como o BIND vai
precisar, contendo os diretórios usr/lib/, usr/libexec/, sbin/, usr/share/ com o diretório
zoneinfo/ e zoneinfo/America e usr/sbin/. Finalmente o diretório bin/ caso seja necessário
(necessário no OpenBSD, no FreeBSD não). Depois, mais um diretório, que será utilizado
pelo bind para guardar as informações de log e informações que nós queiramos. Vale
lembrar que na série 9 do BIND, é o administrador que cria as regras e níveis de logging
data. Então vamos assumir esse diretório de informações diversas como o info/.
Para facilitar a vizualização da estrutura que nós precisamos, veja saída do comando
du:
# du -h /usr/named/
1.0K ./dev
11K ./etc/namedb
80K ./etc
1.4M ./usr/lib
2.0K ./usr/share/zoneinfo/America
3.0K ./usr/share/zoneinfo
4.0K ./usr/share
3.9M ./usr/sbin
83K ./usr/libexec
5.4M ./usr
649K ./bin
2.0K ./info
Agora sim, vamos finalmente garatir todos os arquivos que o bind vai precisar para ser
executado em chroot().
A sintaxe para criação desse do dev/null, logado como superusuário (root) deve ser:
# mknod null c mi mj
Assim o mknod interpreta que o null deve ser criado (opcao "c") com os Minor Number
(mi) e Major Number (mj). Para descobrir esses valores, você deve usar o comando "ls -l
/dev/null" então, no lugar do tamanho do arquivo null, serão mostrados, respectivamente
os valores "mi" e "mj" do seu sistema. Agora você pode criar esse arquivo no seu ambiente
de chroot jail com os mesmos valores.
Esses valores, normalmente são 2 e 2 (2=mi e 2=mj). Se no seu FreeBSD esses valores
também forem esses, então basta digitar os comandos:
# cd /usr/named/dev/
# mknod null c 2 2
As informações devem estar exatamente como no sistema, mas deve-se alterar a senha
para "*" para evitar que ambos se loguem no sistema, e apontar a shell para um
interpretador de comandos não válido, como /sbin/nologin.
# ee /usr/named/etc/passwd
Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida.
# ee /usr/named/etc/master.passwd
Para editarmos, usando o easy editor. Remova todos os users, deixando apenas o root e
o bind e alterando sua shell para uma não válida e alterando sua senha para "*".
As linhas nesse arquivo devem ficar parecidas com as alterações que você deve ter feito,
usando o vipw, como citado no subcapítulo anterior.
Agora o arquivo resolv.conf; Também deve ser copiado do sistema, e não precisa ser
alterado, imaginando-se que seu servidor de nomes já esteja ativo. Se precisar configura-
lo ainda, leia esse capítulo desde o início. Então copiemos:
# cp /etc/resolv.conf /usr/named/etc/
Então, vamos copiar o arquivo group do sistema para o ambiente chrootado, e editar,
para apagar todos os grupos não necessários ao BIND:
# cp /etc/group /usr/named/etc
# ee /usr/named/etc/group
Agora edite o arquivo, com o easy editor, e delete todos os grupos existentes, deixando
apenas o sys e o bind
Então vamos precisar que no nosso ambiente chrootado, esses arquivos também
existam, contudo, com informações apenas dos nossos dois únicos usuários, o root e o
bind.
Para criarmos esses Data Bases de informações dos usuários do sistema, devemos
usar o comando pwd_mkdb; Ele pode criar os arquivos spwd.db e pwd.db em qualquer
diretório, e a partir de qualquer passwd e master.passwd contanto que tenham um
formato válido, interpretável pelo pwd_mkdb.
Portanto, para criar os Data Bases no nosso diretório dentro do ambiente chrootado,
vamos usar o comando, logados como root, da seguinte forma:
A opção "-d" indica ao pwd_mkdb qual o diretório onde os Database Files serão criados,
e o próximo parâmetro indica a partir de qual arquivo essas informações devem ser
criadas.
Pronto, assim você evita que quando for rodar o bind em ambiente chrootado, o
sistema indique o usuário bind como usuário desconhecido.
Para descobrir quais bibliotecas um arquivo binário precisa, você deve usar o comando
ldd.
named
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)
lc_r.5 => /usr/lib/libc_r.so.5 (0x4022a000)
lc.5 => /usr/lib/libc.so.5
Então vamos copiar essas bibliotecas, para o nosso ambiente chrootado, que é onde o
named vai procura-las. Como root, digite:
# cp /usr/lib/libcrypto.so.1 /usr/named/usr/lib/
# cp /usr/lib/libc_r.so.5 /usr/named/usr/lib/libc_r.so.5
# cp /usr/lib/libc.so.5 /usr/named/usr/lib/libc.so.5
Lembre-se, essas bibliotecas com certeza serão outras, de acordo com a versão do seu
sistema operacional, versão do BIND e forma como você o compilou.
No caso da área ser São Paulo (meu caso), então eu vou precisar compiar o arquivo:
/usr/share/zoneinfo/America/Sao_Paulo
Para:
/usr/named/usr/share/zoneinfo/America/Sao_Paulo
Para descobrir onde está o binário named, use o comando: 'whereis named'
E então copie-o para /usr/named/usr/sbin/
Portanto, vamos copiar essa biblioteca pra dentro do ambiente seguro (chroot()
enviroment):
# cp /usr/libexec/ld-elf.so.1 /usr/named/usr/libexec/
Em alguns sistemas operacionais, você vai ter que criar o etc/shells e constar a
existencias dessas shells falsas nesse arquivo. No FreeBSD não foi preciso.
/usr/named: chroot('/')
/dev/
null
/etc/namedb/
named.conf
/etc/
group
master.passwd
passwd
pwd.db
resolv.conf
spwd.db
/usr/lib/
libc.so.5
libc_r.so.5
libcrypto.so.1
/usr/share/zoneinfo/America/
Sao_Paulo
/usr/sbin/
named
/usr/libexec/
ld-elf.so.1
/bin/
false
/info/
Vale lembrar que, de acordo com a versão do BIND, você pode precisar criar outros
diretórios e arquivos, mas esses podem ser facilmente descobertos, ao ler os logs de
provaveis erros, no syslogd ou do daemon. No BIND9x é ainda mais fácil, acionando-se a
opção de debug (-g).
Finalmente, vamos colocar o BIND rodando no nosso ambiente aprisionado. Agora que
você já satisfez todas as dependências de estrutura de arquivos e usuário, já podemos
assegurar nosso servidor de nomes.
Para criar um ambiente de CHroot Jail, no FreeBSD você tem o comando chroot, que
utiliza a função chroot() implementada a nível de Kernel. Para aprender como usar esse
comando com mais detalhes, utilize o manual online:
# man chroot
Mas a sintaxe básica para a utilização do chroot com o BIND, deve ser:
No BIND 8x, onde ainda é necessário apontar o grupo, além de usuário, com a
directiva '-g'.
Ou:
No BIND9x, onde apenas o usuário deve ser indicado, e a opção -g habilita o debug-
mode, para se poder analizar erros, e não lança o processo como background.
Mas...
Essas opções são não viaveis em alguns Linux. O Kernel que você costuma encontrar
esse tipo de incapacidade estão listados no manual online do named (man named).
Para iniciar o named lançando-o em ambiente chrootado e com usuário não privilegiado,
devemos então inicia-lo da seguinte forma:
No BIND9x, a opção "-t" (Troggle chroot() directory) é a mesma, contudo apenas a opção
"-u" deve ser usada para definir qual usuário deve ser o dono do processo. Nessa versão
do BIND, a opção "-g" inicia o Debug Mode, e mantém o processo em foreground.
Pronto, agora sim você já deve estar rodando o seu BIND em ambiente seguro. Se algo
der errado, você pode acompanhar pelos logs que você está acostumado, no BIND8, ou
pelo Debug Mode no BIND9, e descobrir qual foi o erro ou o que faltou no seu ambiente
seguro.
named_enable="YES"
named_program="/usr/named/usr/sbin/named"
named_flags="-t /usr/named -u bind"
Agora você já avisou como o FreeBSD deve iniciar o named, quando necessário. Caso
você costume fazer alterações constantes no seu servidor de nomes e vai ser duro se
acostumar com ficar digitando "/usr/named/usr/sbin/named" toda vez que você quizer
chamar o processo, crie um symlink (link simbólico) apontando o /usr/sbin/named para
o named do seu ambiente seguro: /usr/sbin/named -> /usr/named/usr/sbin/named ;}
Última dica básica: consideramos que os seus arquivos de zona e de reveso já estivesse
no diretório /usr/named, que é onde eles foram indicados à serem criados ao longo desse
capítulo. Se esse não é o seu caso, copie os arquivos ou crie a estrutura de diretórios do
ambiente chrootado de acordo com a sua preferência.
options {
directory "/";
query-source address * port 53;
};
Em alguns casos, o syslogd não vai mais conseguir logar as ações do bind, devido ao
fato do /dev/log não existir no ambiente chrootado. Como solução, devemos indicar ao
syslogd para criar um unix sock em /dev/log com a opção "-a"; Comando: "syslogd -a
/usr/named", estando logado como root.
Feitas essas ressalvas, você está pronto pra configurar seu próprio ambiente chroot()
para o BIND. Preparados da forma como melhor lhe convier. Se quiser, pode até apagar o
diretório /etc/namedb no sistema, visto que agora você vai usar somente o ambiente
chrootado. Mantenha um BACKUP atualizado sempre.
6.5 Configurando um SLAVE NameServer em ambiente CHRootado.
# cp /usr/libexec/named-xfer /usr/named/usr/libexec/
# ldd /usr/named/usr/libexec/named-xfer
# ldd /usr/libexec/named-xfer
libc.so.4 => /usr/lib/libc.so.4 (0x2809c000)
lcrypto.1 => /usr/lib/libcrypto.so.1 (0x40181000)
Feitas essas alterações, você já pode garantir a execussão do seu servidor de nomes
secundário, também em ambiente seguro. Qualquer erro pode facilmente ser descoberto,
analizando-se os logs usuais, os quais você já esta acostumado, e serem corrigidos.
Essas explorações são sempre rapidamente corrigidas, mas não são tão rapidamente
atualizadas pelos administradores de sistemas, visto que a grande maioria não é ligada a
Security Advisories, ou em casos mais comuns, esses administradores tem funções
distintas dentro de uma empresa, e não são somente administradores do sistema,
resultando em uma falta de tempo iminente para cuidar de atualizações e correções de
software.
A forma como o BIND foi escrito até a série 8, é a principal razão dessas explorações.
Agora o BIND foi reescrito, em sua versão 9, e além da tendência a menor exploração e
abuso de seus serviços, o BIND9 incorporou diversas novas características, tanto
relacionadas à segurança do serviço, quanto à eficiência e maiores possibilidades de
configuração no servidor de nomes.
- Segurança no DNS:
DNSSEC (zonas autoritativamente assinadas);
TSIG (transações DNS assinadas) ;
- Views
Um processo do servidor pode diferenciar tipos distintos de "visões" (as views) das
informações de nomes, podendo dividir uma "visão interna" de nomes para alguns clientes,
e outra "visão externa" de nomes para outros clientes.
- Suporte a Multiprocessamento.
- Arquitetura comprovadamente portável.
ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz
ftp://ftp.isc.org/isc/bind9/9.2.0a2/bind-9.2.0a2.tar.gz.asc
Pro FreeBSD, o binário disponível hoje, é a versão 9.1.3 do BIND, disponível em:
ftp://ftp5.freebsd.org/pub/FreeBSD/ports/i386/packages-4.3-stable/All/bind-
9.1.3rc1.tgz
Esses mesmos arquivos (exceto os binários), assim como as versões mais recentes do
BIND9 também estarão sempre disponíveis no mirror brasileiro da ISC, servido pela pop-
mg.com.br no endereço:
ftp://ftp.pop-mg.com.br/pub/isc/bind9/
Normalmente, você já deve ter a OpenSSL instalada e em uso no seu FreeBSD. Para
instala-la, você pode fazer via PORTS, via pkg_add ou pelo fonte, disponível em
www.openssl.org. Informações sobre como instalar software pelo ports ou com pkg_add
disponíveis nos capítulos anteriores dessa documentação.
Essas são as opções para indicar o caminho da biblioteca OpenSSL e para indicar qual
será o diretório de configuração do BIND9. O padrão para essa última opção, se não
alterada, é /etc/, mas como no FreeBSD o padrão é /etc/namedb e nosso capítulo de
configuração do servidor de nomes e capítulo de Chroot Enviroment tratou do caminho
padrão no FreeBSD, e sendo o FreeBSD nosso sistema operacional For Choice, vamos
optar pelo nosso /etc/namedb/.
# cd bind-9.2xx/
# ./configure --with-openssl=/usr/include/openssl --sysconfdir=/etc/namedb
Agora sim, ao final das verificações e dos ajustes de configuração, o BIND9 já está
pronto pra ser compilado:
# make
É de prache recomendarmos que você tenha sempre um backup consistente e
atualizado dos arquivos mais importantes do seu sistema, e isso sempre inclui todos os
seus arquivos do servidor de nomes. Agora, por segurança, faça uma cópia também, além
dos arquivos de configuração, de zonas e reversos usuais, dos binários também,
especialmente os programas nslookup, named, named-xfer e outros que julgar
necessários.
Agora você pode acabar a instalação do seu BIND9. Logado como root, digite:
# make install
O arquivo named.conf é o arquivo que mais ganhou novas opções, exatamente por ser o
arquivo mais importante para o servidor de nomes. Vamos então dar uma ênfase especial
nessas novas mudanças, e entendermos a utilização de todas as novas opções.
Domínio: eeviac.com.br
Servidor Primário: eeviacbsd.eeviac.com.br
Servidor Secundário: xffa.eeviac.com.br
Segundo Secundário: corduroy.eeviac.com.br
Faixa de IPs da Rede: 200.230.200.0 até 200.230.200.63
Portanto Máscara: 255.255.255.192
- Key: Especifica uma chave, para ser usada nas Autenticações e Autorizações,
quando estivermos usando TSIG
Por padrão, o BIND9 já traz algumas ACLs built-in, para facilitar o uso. São elas:
- any: Absolutamente todas as máquinas (hosts) de todas as redes;
- none: Nenhuma máquina (hosts) de nenhuma rede (net).
- localhosts: Todos os endereços IPs atribuídos às interfaces locais. Por
exemplo, interface de loopback lo0: 127.0.0.1; Interface ethernet xl0(placa de rede):
200.230.200.10 (exemplo).
- localnets: Toda a rede, a qual a máquia faz parte. Definida pelo endereço
atribuído a ela, e pelo endereço de broadcast ou máscara de subrede, no sistema
operacional.
acl internas {
192.168.0.0/24;
192.168.1.0/24;
192.168.2.0/24;
};
Nesse exemplo, nós criamos a ACL chamada internas, fazendo referência a nossas
redes internas. Definimos que internas agora quer dizer nossas 3 redes de intranet.
Sempre que o BIND9 se deparar com a palavra de controle 'internas', ele vai saber que
estamos falando dessas 3 redes definidas acima. Máscara /24 indica 24 bits, ou seja, a
rede inteira.
acl secundarios {
200.230.200.9/32;
200.230.200.11/32;
};
Agora definimos que, sempre que dissermos secundários, o BIND deve interpretar como
sendo nossos servidores secundários, os dois endereços IPs que fazem parte da nossa
ACL. A máscara indica 32 bits, ou seja, é um host único.
acl nonsenseisp {
200.205.2.0/24;
200.205.3.0/24;
};
Essa ACL define que as duas redes (24 bits) nessa definição, devem ser compreendidas
sempre que mencionarmos a a expressão nonsenseisp. Caso você encontre algum ISP que
sempre mantém problemas como lamme delegations ou qualquer outra má configuração
nonsense ;}
Lembre-se que, os nomes para as ACLs e o conteúdo das mesmas são definidos
exclusivamente por você, nonsenseisp por exemplos é um tipo de expressão que não quer
dizer muita coisa, e deve ser compreendido apelas pelo administrador que criou essa ACL.
controls {
inet ( ip_addr | * ) ( port 'ip_port' ) allow endereços_permitidos
keys lista_de_chaves_permitidas;
inet [...];
};
Nos endereços permitidos, pode ser especificada uma ACL previamente declarada.
Vejamos o exemplo a seguir:
controls {
inet 200.230.200.10
allow {
localhost;
internas;
}
keys {
chaves_rndc;
chaves_privadas;
}
};
Com essa regra, abrimos um canal de controle, na porta padrão (953) da interface
externa do servidor (endereço IP 200.230.200.10) e demos permissões para acesso nesse
canal de controle para localhost e para internas onde a segunda é uma ACL previamente
declarada no nosso arquivo de configurações. Definimos também duas chaves, as
chaves_rndc e chaves_privadas para serem as nossas atribuições de assinatura digital,
pra segurança das transações DNS.
As chaves usadas foram previamente criadas. Veja Instrução Keys. A sintaxe de canais
de controle não é mais compativel com as implementadas na série 8 do BIND.
A instrução keys é usada para se criar assinaturas digitais durante as transações DNS,
ou seja, é a característica principal da nova função 'TSIG' do BIND9. A declaração dessa
chave é definida por um nome de chave, chamado também de key_id, seguido de um tipo
de algorítmo a ser seguido, e finalmente a chave, propriamente dita. Atualmente apenas o
algorítmo hmac-md5 é suportado para a autenticação TSIG.
key key_id {
algorithm algorítmo;
secret chave;
};
Foi criada então, uma chave de assinatura digital, com o nome servidores-externos. A
utilização dessa chave deve ser feita junto da instrução server, no arquivo de configuração
do BIND. Você vai ver mais detalhes na seção que aborda as Assinaturas de Transações
(Transaction SIGnatures, TSIGs) a seguir.
A sintaxe é simples:
include arquivo;
include servidores-externos.key;
Essa é uma das mais importantes e funcionais novidades do BIND9. Nessa nova versão,
as definições de logs apenas passam a funcionar quando o parsing de toda a declaração
das regras de logs são lidas, ou seja, apenas quando o BIND termina de ler as instruções
de logging é que o log começa a ser gravado. Até isso acontecer, as mensagens são
enviadas normalmente ao daemon de logs do sistema. Em casos extremos, para se
solucionar problemas deve-se usar a opção "-g" para iniciar o BIND. Essa opção inicia o
named em foreground e com o nível alto de debug para a saída de informações.
São utilizadas duas especificações de chamadas junto à instrução logging. Elas são
chamadas de "channel" e de "category".
Veja a sintaxe básica da instrução Logging:
logging {
channel {};
category{};
};
logging {
channel "nome_do_canal" {
file "path(caminho)";
versions número_específico OU unlimited};
size tamanho;
syslog opção_syslog;
null;
print-category yes|no;
print-severity yes|no;
print-time yes|no;
};
category nome_da_categoria {
nome_do_canal1;
nome_do_canal2;
nome_do_canalX;
...
};
};
Todas as espeficicações de logs tem sua saída definida em um ou mais canais de log,
chamados de channels. Você pode criar quantos canais quizer, para separar suas
definições de logs. Você vai indicar onde os logs serão armazenados, e de que forma, se
em forma de arquivo comum, ou um log criado por um daemon específico para isso. Ao
usar o Syslog a opção "local3" é comumente atribúida para informar o BIND da utilização
do daemon. Você vai também indicar o nível de informação que será logada, utilizando a
opção severity. Quando um nível não é aplicado, o padrão é a utilização do nível info.
A especificação file indica ao BIND para gravar todas as informações de acordo com o
nível definido no severity em um arquivo de texto, especificado no caminho dado. Em
ambientes seguros, utilizando ambiente chrootado, é recomendado uma definição
parecida com file info/tipo_de_log.log como foi tratado no nosso capítulo anterior. Esse
tipo de arquivo ainda pode ser controlado, pelo BIND, controlando que tamanho máximo
esse arquivo pode alcançar, e quantas versões do mesmo poderão existir. A opção size
define o tamanho máximo que esse arquivo vai ter. E a opção versions define quantos
arquivos de logs poderão automaticamente ser criados. Por exemplo, se você definir
versions 2; vão sempre existir os arquivos arquivo.log e arquivo.log.0 balanceados com o
tamanho especificado em size.
Se você espeficiar syslog como destino dos logs, então o sistema vai usar o syslogd
para prover todos os logs necessários, conforme especificados por severity. Contudo, é
requerido uma opção_do_syslog que define a forma como o syslogd vai logar essas
informações. A opção normalmente usada é a "local3". Para conhecer as outras opções
existentes, leia a man-page do syslogd (comando man syslog) ou os cometários no seu
arquivo "/etc/syslog.conf".
São as categorias de logging do BIND9. A utilização dessa categoria pode ser feita de
duas formas, a primeira é utilizar categorias como agrupamentos de canais de logs. Dessa
forma, você pode criar um nome para uma categoria, e dizer que aquela categoria conterá
as informações dos vários canais de logs que você criou com a função channel{}; e usar
essa definição posteriormente.
- default: é a definição de categoria padrão, que é utilizada quando não são definidas
categorias para um canal de log. É similar ao local3 do syslogd em níveis generalizados de
informações.
- database: são informações referentes as dbs internas, utilizadas pelo named para
controlar a autoridade sobre zonas, reversos e dados de cacheamento.
- security: informações de Negação ou Permissão de requisições sobre informações
feitas ao BIND.
Agora já sabemos como definir nossos canais de logging e quais tipos de categoria
podemos usar para definir os níveis de informações à serem logadas. Veja agora um
exemplo de configuração básica utilizando a instrução logging:
logging {
channel "named_log" {
file "info/named.logs";
severity info;
print-category yes;
print-severity yes;
print-time yes;
};
channel "named_erro" {
syslog local3;
severity error;
print-category yes;
print-severity yes;
print-time yes;
};
category "security" {
"named_log";
"named_erro";
};
category "xfer-out" {
"named_log";
};
category "xfer-in" {
"named_log";
};
};
Foram criados então, dois canais de logging, um canal de logs gerais, chamado
named_log e um canal de logs específico para armazenarmos informações de erros, o
named_erro. No canal de logs mandamos gravar as informações em um arquivo,
localizado no caminho "info/named.logs" e no canal de erros, mandamos logar com o
daemon syslod. Definimos as prioridades de informações com severity nos dois canais, de
mandamos logar as informações definidas pela categoria, pela prioridade e a hora em
questão, com as opções print. Depois definimos as categorias, atribuindo uma a uma ao
canal que nós criamos.
Outra novidade, a opção named-xfer ainda existe, no BIND9, mas ela se tornou
obsoleta e não usável, já que o novo bind incorpora essa função automaticamente em seu
servidor. Portanto o programa named-xfer não é mais necessário para os servidores de
nomes secundários. A opção notify por exemplo, avisa quando uma zona autoritativa foi
modifcada, e está pronta pra transferência ou atualização.
options {
directory "/";
allow-transfer { 200.230.200.9; };
allow-recursion { 200.230.200.0/24; };
statistics-file "/info/named.stats";
dump-file "/info/dump.db";
pid-file "/info/named.pid";
version "Versao Indisponivel";
listen-on port 53 { 200.230.200.10; };
query-source address 200.230.200.10 port 53;
transfer-source 200.230.200.9 port 53;
auth-nxdomain no;
};
A opção directory define o working directory para o nosso servidor de nomes. Funciona
da mesma forma que na versão 8 do BIND. No exemplo acima fica claro que nosso
servidor de nomes vai estar rodando em ambiente seguro (CHRoot Enviroment), ou seja,
CHRootado, porque definimos a raiz "/" como diretório de configuração do nosso servidor
de nomes.
Onde "secundarios" é uma ACL que define quais são nossos servidores slaves.
A opção pid-file indica onde o BIND deve criar seu arquivo de texto com o número de
Process IDentification.
Com essas opções você já pode colocar o seu servidor de nomes no ar, rodando com
traquilidade. Lembre-se de usar ACLs sempre que possível, porque ajudam na
administração e consequente segurança do servidor de nomes.
7.4.7 Instrução Server;
server endereço_ip {
bogus yes|no;
provide-ixfer yes|no;
request-xfer yes|no;
transfers número;
};
A opção bogus da instrução server define um tipo de servidor que possivelmente está
dando informações errôneas sobre zonas e nomes. A palavra bogus pode ser livremente
traduzida como "bobo". Se um servidor for definido como bogus as informações providas
por eles serão consideradas com um nível mais baixo de prioridade. A padrão para essa
opção é "no". Até a data atual essa opção não havia sido implementada no BIND9.
A opção request-ixfer define que o servidor local vai estar agindo como servidor de
nomes secundário, e que vai tratar o servidor especificado na opção server como o
primário. Ao tentar atualizar suas zonas secundárias, ele sempre tentará que essas
requisições dejam incrementais, caso esteja definida opção yes. Se não especificada, essa
opção também assume o resultado global definido em options{};
A opção key é usada para definir um nome de chave, o key_id definido por uma
instrução key, para garantir transação segura quando dois servidores estiverem se
comunicando.
Essa opção define uma trusted-key para um security-root do DNSSEC. DNSSEC vai ser
tratado ao longo dessa documentação, mas é necessário ter um conceito das trusted-keys.
Quando existe uma chave conhecida para um servidor de nomes remoto, mas essa chave
não pode ser obtida por transferência DNS porque o servidor não tem sua assinatura
digital corretamente configurada, então são definidas essas trusted-keys, com conteúdo
conhecido pelas keys, ou seja, chave de base 64, protocolo e agorítmo comuns, para
definir um security-root de confiança. Então a validação de requisições DNS são efeutadas
nos sub-domínios do security-root.
Cada instrução view permite a divisão das informações que o servidor de nome irá
responder, diferenciando pelos endereços IPs, que tipo de resposta cada cliente deverá ter.
Vale lembrar que a ordem das definições de views é importante, já que a resposta será
dada de acordo com a primeira cláusula view onde o endereço IP do cliente for
reconhecido.
view nome_da_view {
match-clientes { lista_de_endereços };
conjunto_de_opções_da_view;
opção_de_zona;
};
As zonas definidas dentro de uma view, serão apenas vistas pelos clientes que tiverem
seu endereço reconhecido pela lista de acessos dessa view. As opções de view
(conjunto_de_opções_da_view) podem ser definidas quase em sua maioria, com as mesmas
instruções existentes na opção options{};. Quando não definidas, as opções globais
definidas em options{}; serão utilizadas.
Como uma zona comum de nomes, é necessário ter uma opção HINT para as zonas
definidas dentro de uma view. Se a opção "IN" for assumida como a classe da zona,
dentro da view, então uma HINT não precisa ser especificada, porque as classes 'IN' as
tem pré-configurada.
view "internet" IN {
match-clients { any; };
zone-statistics yes;
recursion no;
zone "eeviac.com.br" {
type master;
file "db.eeviac.externo";
};
};
view "intranet" IN {
match-clients { 192.168.1.0/24; };
zone-statistics yes;
recursion no;
zone "eeviac.com.br" {
type master;
file "db.eeviac.interno";
};
};
Agora, nessas duas views nós definimos visões distintas para a mesma rede, de acordo
com os clientes. Fizemos um DNS Spliting com um mesmo servidor de nomes, e
separamos as informações que apenas a nossa intranet pode ter acesso, das informações
que toda a internet pode ter.
Usando a opção match-clients definimos quem pode ter acesso a qual zona (zone file)
definida com a instrução zone {}; que será explanada à seguir. Definimos opções de zona
estática e de recurssão. Note que, na primeira view foi usada uma ACL padrão, ou seja,
você pode fazer uso de ACLs que você criar para definir os acessos às views.
Os arquivos de zonas são os mais importantes no servidor de nomes. São eles que
conterão as informações que o seu servidor de nomes deve responder. Esses arquivos de
Zone foram explicados em detalhes no Capítulo 5. No BIND9, esse arquivo ganhou
algumas características a mais que devem ser notadas. O número serial nos arquivos de
zonas agora devem ser do tipo "integer" ou seja, números inteiros. A cláusula $TTL (Time
to Live) se tornou obrigatória no cabeçalho de todos os arquivos de zonas.
As zonas podem ser definidas por classes, se não houver essa definição, por padrão o
servidor de nomes assumirá a classe "IN" indicando que essa é uma zona comum à
Internet. A zona CHAOS criada em 1970 pelo MIT também está implementada, assim
como a zona HESIOD (ou apenas HS), também criada pelo MIT para compartilhar
informações de usuários, grupos, impressoras, etc...
A zona do tipo HINT que define os Root NameServers (".") são obrigatórias na definição
do arquivo de configuração do BIND. A sintaxe de definição de uma zona dentro do
arquivo named.conf permanece igual. O conteúdo da zona agora assume novas
características, como informações "A6" para definição de endereçamento IPv6. Para
maiores informações sobre essas novas opções existentes, veja o manual online: man
named, man bind.
zone "." {
type hint;
file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "eeviac.com.br"{
type master;
file "db.eeviac";
Lembrando que as entradas "A" podem ser substituídas por "A6" se formos definir
endereçamento IPv6, e "DNAME" para delegar endereçamento reverso IPv6 de nomes.
Esse processo local se chama Resolver Daemon (lwresd). Por padrão, as aplicações que
fazem uso da biblioteca lwres pra resolução de nomes, farão uma conexão UDP comum,
na porta 921 do endereço de loopback IPv4 (127.0.0.1), e é onde esse servidor de
resolução deve estar ouvindo. Essa definição de endereço e porta pode ser modificada,
usando a directiva "lwserver" no arquivo de configuração do resolver do sistema, o
"/etc/resolv.conf".
lwres {
listen-on { lista_de_endereço/lista_ACL };
view nome_da_view;
ndots número;
};
A partir disso, o named vai passar a agir como um lowresd, na porta 53, do endereço
de loopback (127.0.0.1) ou na porta e endereço especificados na directiva listen-on{}; Pode
ser utilizado também as views da mesma forma como foram descritas anteriormente. Se
não houver uma view especificada, a view padrão é utilizada. As directivas "search" e
"ndots" tem a mesma função de quando utilizadas dentro do arquivo "/etc/resolv.conf".
O utilitário de administração rndc ainda pode ter várias outras funções futuramente
implementadas, em novas versões, de acordo com as necessidades. A utilização desse
aplicativo requer obrigatoriamente um arquivo de configuração, chamado de
/etc/rndc.conf.
key chave_rndc {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};
options {
default-server localhost;
default-key chave_rndc;
};
key chave_rndc {
algorithm hmac-md5;
secret "lZ12asdDfWwqqertTtys";
};
controls {
keys { chave_rndc; };
};
Agora sim, qualquer comando deferido com o programa rndc estabilizaria uma conexão
digitalmente assinada na porta 953 da máquina local, e efetuaria a transação ordenada.
Existem algumas formas de se gerar uma chave secreta de comunicação entre duas
máquinas, contudo, é importante que se satisfaçam duas dependências. A primeira, é
óbvio, deve ser que as chaves conhecidas em ambas as pontas sejam idênticas, e a
segunda, que essas chaves sejam tratadas pelo mesmo nome. Portanto devemos definir
um nome e um segredo para criarmos uma chave secreta de autenticação.
A geração dos segredos compartilhados entre as chaves podem ser efetuados de duas
formas. A primeira é automatica, e a segunda, manual.
AUTOMATICA:
Para gerar uma chave de forma automática, com 16 bytes (128 bits) e algorítmo hmac-
md5, você pode por exemplo utilizar o comando:
MANUAL:
Para gerar uma chave de forma manual, você precisa apenas cumprir algumas
dependências. Basta saber que uma chave é apenas um conjunto randômico de
caracteres ascii, de base-64. A maioria dos caracteres ascii, contanto que não se inclua
caracteres especiais, são base-64, e portanto são caracteres válidos. O tamanho da chave
deve ter um número de caracteres múltiplo de 4. Portanto qualquer sequência de
caracteres ascii não especiais, com tamanho múltiplo de 4 é uma chave de segurança
válida. Ex: "IhQIU=ihIL-HLAui" é uma key válida.
Como ja dito, a chave deve ser conhecida por ambos os servidores que se comunicarão.
A chave deve ser definida com a opção key já descrita anteriormente, no arquivo
named.conf do servidor. Portanto é recomendado que esse arquivo não possa ser lido por
todos os usuários do sistema, apenas ao dono do processo (modo: 'chmod 700' ou
necessário), ou ainda que a chave esteja anunciada em um arquivo separado, com modos
de permissões seguros no sistema, e que pode ser chamado pelo arquivo named.conf com
a opção include.
Para instruir o servidor a utilizar aquela chave, deve-se usar a opção server{}; também
já descrita anteriormente. Existem ainda as opções de permissão para determinada
função à ser implementada. Essas opções são:
allow-query{};
allow-transfer{};
allow-update{};
Elas devem ser utilizadas no named.conf para definir regras de controle específicas
para as transações. São como ACLs do sistema, mas referente à comunicação baseada em
chaves. Por exemplo:
Essa definição portanto permite que sejam realizadas "Dynamic Updates" (atualizações
dinâmicas) apenas entre os hosts que tenham a chave "chave_master_slave" em comum.
Basicamente, cria-se uma chave para a zona que se quer autenticar, e se especifica a
chave (de extensão .key) com a opção "$INCLUDE" no arquivo da zona que se quer
autenticar. Na prática, o BIND9 oferece várias ferramentas para a criação dessas chaves,
e para assinatura de zonas.
Ambos, dnssec-keygen e dnssec-signkkey são ferramentas desenvolvidas para a criação
de chaves públicas (.key) e privadas (.private) de criptografia, e para assinatura de zonas.
O programa dnssec-signzone assina a zona específica e cria uma zona assinada que
deve ser chamada pelo arquivo named.conf. A sintaxe dos comandos pode ser facilmente
assimilada, lendo-se as páginas de manuais dos mesmos. DNSSEC ainda não está
completamente implementado no BIND9, portanto possíveis modificações ocorrerão nas
próximas versões.
Outras informações, e algum detalhe que por ventura não tenha sido considerado aqui,
pode ser encontrado no diretório "doc/arm/" em formatos DocBook XML e HTML
distribuído junto ao fonte do BIND9 nos endereços citados no início do capítulo.
Excluindo DNS Security (DNSSEC), toda informação aqui tratada foi implementada de
forma prática antes de ser documentada, em dois servidores distintos, o servidor principal
de internet da Faculdade de Tecnologia de Taquaritinga, e o servidor primário do provedor
de serviços internet (ISP) Mac3, de Ibitinga.
Espero que esse documento auxilie o leitor e supra suas necessidades básicas.
Dúvidas que não surgiram durante o curso, serão respondidas à medida do possível,
desde que a leitura dos capítulos prévios sejam consideradas. Estou disponível para
ajudar no que for possível: eksffa@fatectq.com.br
Bibliografia dos Capítulos 5, 6 e 7.
Chroot-BIND HOWTO
Scott Wunsch, scott @ wunsch.org
http://www.losurs.org/docs/howto/Chroot-BIND.html
V.0.3br_pt
Sumário.
4.3.1. icmptypes;
4.3.2. tcpflags, setup & established;
4.3.3. ipoptions;
5. Logs (Logging).
2. Acionando o Ipfirewall(4);
options IPFIREWALL
Assim você vai automaticamente adicionar uma regra pra permitir todo o
tráfego da rede, ao invés de bloquea-lo, evitando assim que você perca a conexão com a
máquina remota. De qualquer forma, é recomendável que se carregue o ipfirewall(4) dessa
maneira em máquinas locais também, especialmente se elas estiverem conectadas em
rede, pra não perder uma conexão em andamento.
Pra você fazer isso, basta adicionar duas linhas no seu rc.conf, uma que vai
acionar o firewall na inicialização da máquina, e outra pra definir o tipo de firewall que vai
ser iniciado. No caso firewall do tipo aberto (OPEN). Então basta adicionar as seguintes
entradas no seu /etc/rc.conf:
firewall_enable="YES"
firewall_type="OPEN"
Existem ainda outros tipos de firewall previamente definidos no
/etc/rc.firewall, mas nós vamos tratar deles posteriormente. Por enquanto vamos
começar com uma política de firewall aberta (OPEN). Ainda existe uma alternativa muito
boa pra se definir uma política aberta como padrão pro ipfw(8) no kernel. Você pode
simplesmente adicionar a seguinte linha no arquivo de configuração do seu kernel:
options IPFIREWALL_DEFAULT_TO_ACCEPT
Ainda existem outras opções pro ipfirewall(4) que são possíveis se nós
formos acionar o firewall de forma estática no kernel, até o início da série 4.x do FreeBSD
algumas dessas opções não podiam ser acionadas se não fosse de forma estática no
kernel, mas nas versões mais recentes foram definidas algumas variávies do kernel,
mutáveis via sysctl(8), que não restringem mais essas opções ao kernel estático. Além do
IPFIREWALL_DEFAULT_TO_ACCEPT nós ainda temos as seguintes opções:
options IPFIREWALL_VERBOSE
options IPFIREWALL_FORWARD
options IPFIREWALL_VERBOSE_LIMIT=#
options IPV6FIREWALL
options IPV6FIREWALL_VERBOSE
options IPV6FIREWALL_VERBOSE_LIMIT=100
options IPV6FIREWALL_DEFAULT_TO_ACCEPT
Ainda que você defina ou não o tipo de firewall que você vai estar
trabalhando, sempre que a opção firewall_enable="YES" é adicionada no rc.conf e o
sistema é iniciado, o /etc/rc.firewall é lido e executado também, a partir das
configurações definidas no rc.conf, e os seguintes comandos são sempre adicionados ao
ipfw(8):
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
Essa regra permite que todo tráfego externo seja aceito como entrada (com
excessão pro loopback, já que a rede localhost é previamente bloqueada) e todo o tráfego
interno seja aceito como saída. A mesma função do IPFIREWALL_DEFAULT_TO_ACCEPT
no kernel. Se a política aberta é definida no kernel, a regra número 65535 vai ser
automaticamente carregada como "allow ip from any to any" no lugar de "deny ip from
any to any", posteriormente adicionando a regra número 65000. Isso cria uma
redundância de política de firewall aberta. Então, é mais indicado definir o tipo de firewall
como "UNKNOWN" (desconhecido) se você adicionou a política aberta
(IPFIREWALL_DEFAULT_TO_ACCEPT) no kernel, e não quer permitir mais nenhuma
regra do rc.firewall. Para isso, inclua as seguintes linhas no seu /etc/rc.conf:
firewall_enable="YES"
firewall_type="UNKNOWN"
- Você vai ser obrigado a se familiarizar com o uso do ipfw(8) e sua sintaxe,
se tornando mais experiente na definição de firewall, e ficando mais a vontade com o
ipfw(8).
firewall_enable="YES"
firewall_type="/etc/rc.firewall.rules"
Dessa forma você vai poder definir sua própria configuração de firewall no
arquivo /etc/rc.firewall.rules, o qual será carregado sempre que seu firewall for iniciado.
Se você preferir ainda que seu firewall seja iniciado de forma silenciosa, basta incluir no
rc.conf:
firewall_quiet="YES"
O formato do seu conjunto de regras será apresentado de forma um
pouquinho diferente nesse arquivo, em relação ao que você encontra no rc.firewall. O
motivo é simples, o rc.firewall é um 'shell script' sh(1) escrito de forma que possa rodar
por si próprio, enquanto o arquivo que define as suas regras personalizadas estão ali
simplesmente para serem processadas pelo ipfw(8). A principal diferença é que você não
vai usar nada correspondente à variável ${fwcmd} usada no rc.firewall. Simplesmente as
regras. Posteriormente, vamos construir um arquivo de regras próprio, e então vamos ver
isso passo-a-passo.
Dessa forma, você vai estar listando todas as regras ativas no momento,
seguindo a ordem do número da regra.
Por exemplo:
Dessa forma, ainda que, a regra número 00103 tenha sido adicionada antes
da regra 00101, a de número menor será mostra antes, porque a ordem das regras
também influi na forma como o ipfirewall(4) vai se comportar.
Pra mostrar a data e hora da última vez que um pacote coincidiu com uma
regra basta usar a opção timestamp do ipfw(8):
root@eeviac~# date
Sat Sep 22 19:12:24 GMT 2001
Ou seja, nesse caso, a última vez que a regra 00101 bloqueou um pacote foi
na madrugada do dia anterior, a regra 00102 bloqueou um pacote também aos 33
minutos de 2 dias atrás, e o último pacote permitido pelo firewall foi há 9 segundos.
Detalhe no comando date posterior que ilustra a data corrente.
"allow" | "pass" | "permit" | "accept" - Quando uma regra define essa ação,
sempre que um pacote combinar com essa regra, será permitido seu roteamento pelo
firewall, e o processamento das regras *pra esse pacote* termina.
"deny" | "drop" - Qualquer pacote que combinar com uma regra cuja ação
seja "deny" ou "drop" são silenciosamente bloqueados pelo firewall, e o processamento das
regras pra esse pacote termina.
Essa regra nega todos os pacotes vindos de qualquer origem e indo pra
qualquer destino.
"reset" - Quando um pacote encontra uma regra com essa ação, o pacote é
bloqueado, e o ipfirewall(4) tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço
de origem do pacote. O processamento das regras pra esse pacote termina. Como esse
tipo de regra apenas se aplica pra pacotes TCP, o protocolo especificado na regra deve ser
"tcp", para que apenas tais pacotes sejam processados por essa regra, e não todos (proto
"all") os protocolos de pacotes IP.
Vale notar que o uso do "reset" pode ser muito interessante pra enganar
ferramentas que escaneiam as redes (network scanners), já que normalmente podem
detectar um serviço por trás de uma porta filtrada, mesmo que ele esteja por trás de um
firewall de bloqueio. Por outro lado, se alguém estiver praticando um ataque do tipo
"network flood" em uma porta específica a qual o ipfirewall(4) está configurado para
responder com pacotes RST, isso duplicaria o uso da sua banda de rede. Uma solução
simples é bloquear, com uma regra prévia o endereço da máquina que está agindo dessa
forma, endereço esse obtido de forma dinâmica por monitoramento.
Essa regra faria com que todo o tráfego vindo da rede 192.168.1.0/24 e
indo pra qualquer destino seja processado pelas regras a partir da regra de número 1800
Como você pode ver existe um padrão definido. O número de endereço total
de uma rede sempre sobra a partir da máscara que lhe foi atribuida, e o número total de
Ips disponíveis (que podem ser usados por estações) é sempre o total disponível na rede
menos 2 (total – 2). O motivo também é simples, para cada rede/subrede existem dois
endereços IP reservados para o endereço da rede e para o endereço de broadcast da rede.
O último octeto da máscara de rede (netmask) começa com 255 e sempre se decrementa
em valores múltiplos de 2, enquanto o bitmask se decrementa em múltiplos de 1.
Vamos ver, de forma sucinta como usar a tabela acima. Vamos descobrir
então qual é a faixa de IPs que compõe uma subrede cujo endereço seja:
172.16.100.32/28
"unreach <código>" - Qualquer pacote que combine com uma regra cuja
ação seja "unreach", serã respondido com um código 'ICMP unreach' (código ICMP de
indisponibilidade), e posteriormente a leitra do conjunto de regras será terminada. As
possibilidades de códigos pro 'ICMP unreach' pode ser indicada por número ou por nome.
Segue agora uma breve lista de 'ICMP unreach codes' (os códigos em questão) e seus
nomes correspondentes. Se você não sabe onde esses códigos são utilizados, não tem
porque você tentar usa-los:
net 0 net-prohib 9
host 1 host-prohib 10
protocol 2 tosnet 11
port 3 toshost 12
needfrag 4 filter-prohib 13
srcfail 5 host-precedence 14
net-unknown 6 precedence-cutoff 15
host-unknown 7
isolated 8
add 1200 allow all from any to any out via any
Você vai notar que, quando você listar as regras de firewall, as entradas que
estiverem usando "in" ou "out" combinadas com "via", não apresentarão a utilização do
"via" mas apresentará a citação "recv" ou "xmit", dependendo da definição de um "in" ou
um "out" respectivamente. Veja só:
root@eeviac~# ipfw add 7000 allow all from any to any out via xl0
root@eeviac~# ipfw list | grep 7000
07000 allow ip from any to any out xmit xl0
root@eeviac~#
Portanto, você pode usar "recv" ou "xmit" no lugar de "via" quando você for
criar alguma regra que faça uso de "in" e "out", contudo isso não é preciso, o ipfirewall(4)
distingui se a interface está recebendo o transmitindo o dado, e, além do que, essa
definição pode confundir usuários não experientes.
No geral, essas opções oferecem muito mais controle sobre o tráfego da rede
em um sistema de interfaces múltiplas, e qualquer outro sistema em geral, visto que elas
permitem a filtragem de pacotes específicos vindo para o firewall, saindo por ele, e se
deslocando através de uma interface especificada.
Se você ficou curioso pra saber como esses tipos ICMP, especialmente o tipo
3, correspondem aos códigos de indisponibilidade que podem ser criados com a opção
"unreach", então, saiba simplesmente que o tipo 3 identifica qualquer um desses códigos,
ou seja, todos. Usar filtros de pacotes ICMP é muito útil, especialmente pra controlar
ping; por exemplo, você pode permitir que qualquer cliente dentro da sua rede interna
pingue qualquer estação pra fora da rede, enquanto você bloqueia que qualquer estação
externa pingue o seu gateway, ou qualquer outro cliente interno. As três regras a seguir
definem isso facilmente:
"tcpflags <flag>" - Essa opção filtra qualquer pacote TCP cujo cabeçalho
contenha alguma das flags (opções) identificadas. Uma definição inversa também pode ser
utilizada se colocarmos uma '!' (exclamação) antes da <flag>, dessa forma filtrando todos
os pacotes TCP que não possuam a <flag> em questão. Veja as opções de 'flags':
A <flag> SYN é a mais interessante, visto que ela é enviada quando uma
conexão TCP é iniciada. Por ser tão importante, existe inclusive uma opção separada do
ipfw(8) dedicada especialmente pra definir pacotes TCP cujo cabeçalho tenha a flag SYN
ajustada. Essa opção se chama "setup". É claro que só podemos trabalhar com a opção
"setup" quando o protocolo indicado é o "tcp".
"setup" - Qualquer regra contendo essa opção vai filtrar todos os pacotes
TCP cujo cabeçalho indique a flag SYN ajustada. Dessa forma, se quizermos
simplesmente negar todos os pacotes TCP que estiverem entrando no firewall com o
cabeçalho SYN definido, temos duas opções:
OU SIMPLESMENTE:
Em cada uma dessas regras, a mesma ação é tomada: todos os pacotes TCP
SYN vindos de qualquer (any) origem para qualquer (any) destino serão negados. Vale a
pena ilustrarmos a necessidade do protocolo ser "tcp" quando trabalharmos essas regras.
4.3.3. ipoptions;
Quando você for usar a opção "frag" pra filtrar (e bloquear) os pacotes
fragmentados, tem duas regrinhas básicas que você deve seguir. A primeira é que você
não pode usar "frag" quando também estiver usando a opção "tcpflags"; você define
qualquer pacote fragmentado, ou não define nenhum. A segunda: você também não pode
utilizar o "frag" se estiver especificando portas TCP ou UDP; você bloqueia todos os
pacotes fragmentados, não importando pra qual porta ou serviço eles estejam sendo
enviados. Dito isso, podemos facilmente definir uma regra pra negar todos os pacotes
fragmentados que estiverem entrando na rede:
Uma poderosa função que outros firewall (como o IPFilter) não possuem é a
filtragem de pacotes baseada em GID/UID. O Ipfirewall(4) tem a capacidade de filtrar
pacotes de acordo com o UID ou GID do dono do processo o qual originou uma conexão.
Por motivos lógicos só se pode filtrar pacotes que tenham sido gerados por processos
locais. As opções a serem utilizadas são "gid" ou "uid" seguidos do GID/UID ou do nome
do usuário/grupo que estivermos filtrando.
Essas regras permitem que apenas o usuário 'patrick' vai poder utilizar a
alias de IP (Apelido de IP, IP-Alias ou IP vhost) 172.168.0.10 pra estabelecer conexões TCP
pra fora da rede. Ninguém mais será permitido pendurar Bots, Clientes de IRC ou
qualquer outra coisa que precise estabelecer conexão TCP (quase tudo) nesse endereço IP.
O protocolo UDP também pode ser usado para filtragem de pacotes baseada em UID/GID,
contudo nenhum outro protocolo fora esses dois podem.
Por motivos de segurança, talvez seja necessário voce logar o tráfego de rede
de um usuário em particular, e nesse caso o filtro baseado em UID/GID também viria
bem a acalhar. Na verdade sempre que se queira definir um comportamente distinto do
firewall com base no usuário que acessa o serviço, o UID/GID do ipfw(8) sempre vem bem
a acalhar. Uma pequena dica é sempre definir as regras baseadas em UID/GID antes das
outras regras, visto que o ipfirewall(4) termina a verificação da lista das regras quando
um pacote combina com alguma das regras em uso. Isso garante desempenho e evita que
se bloqueie ou permita um pacote antes de verificar qual usuário originou o tráfego.
5. Logs (Logging);
5.1. Propriedades de Logs;
Mas logar também tem o seu lado negativo, se você não for cuidadoso.
Dependendo do tipo de dado que você está logando você pode se perder com a
abundância de mensagens, e também utilizar muito espaço em disco pros arquivos de
logs. Ataques de negação de serviço que tendem a sobrecarregar discos rígidos é um dos
tipos mais antigos de atividade má intencionada, e por incrível que pareça ainda é
sinônimo de perigo pra administradores imprudentes. Por isso a importância de se definir
que tipos de regras serão logadas. Normalmente logar pacotes permitidos de serviços
públicos (como WWW) não é uma boa indéia, visto que o próprio serviço (servidor WWW)
também mantém logs das atividades de acesso, e a frequência de pacotes em um serviço
como esse é muito grande.
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=#
options IPFIREWALL_VERBOSE_LIMIT=10
Com essa entrada definida no seu kernel, apenas 10 mensagens
consecutivas a respeito de determinada conexão serão logadas no syslogd(8), e todas as
outras ocorrências seriam identificadas sob uma expressão genérica como por exemplo:
1) Crie o seu novo arquivo de log para o ipfw(8) e, como alternativa, crie
também o diretório de logs que você achar conveniente. Vamos assumir então que você
quer que todos os logs relativos ao ipfirewall(4) sejam armazenados em
/var/log/ipfw/ipfw.log. Dessa forma você vai ter que criar o diretório em questão
(/var/log/ipfw) e em seguida o arquivo de log (ipfw.log) sob tal diretório, pra isso vai
utilizar o comando touch(1):
!ipfw
*.* /var/log/ipfw/ipfw.log
Atente pra usar <TAB> (tecla tab) nesse arquivo ao invés de espaços
simplesmente. Mesmo assumindo que usar "tabs" não é obrigatório no FreeBSD pro
arquivo /etc/syslog.conf, é de bom costume fazê-lo, caso você trabalhe também com
outros UNIX, cuja maioria não aceita espaços no syslog.conf(5). Portanto mesmo você
podendo ignorar a mensagem de advertência no início do /etc/syslog.conf, é sempre bom
manter o bom hábito seguro de usar o syslog.conf(5) da forma indicada por ele.
Você vai reparar que as mensagnes do tipo "last messages repeated # times"
(ou seja: últimas mensagens repetidas # vezes) serão também logadas, além desse arquivo,
pra qualquer outro cujo syslog.conf(5) aponte as seguintes entras:
*.err root
*.notice;news.err root
*.alert root
*.emerg *
Então vamos resumir o que deve ser feito quando você for configurar seus
logs pelo arquivo de configuração syslog.conf(5):
Não altere as mensagens que serão enviadas ao usuário Root se ele estiver
logado. Indique os mesmos alertas pra um usuário que você usa com mais frequência.
Agora que o ipfirewall(4) está configurado pra logar todas suas atividades,
você deveria pensar seriamente em configurar o newsyslog.conf(5) de forma a garantir que
o newsyslog(8) vá rotacionar os logs do ipfirewall(4), ou, como alternativa, optar por algum
outro mecanismo de rotacionamento de logs. Pra se ter uma boa noção de todas as
configurações possíveis do newsyslog.conf(5) é recomendado que você leia a página de
manual (man newsyslog.conf) do arquivo. Essa é uma poderosa ferramenta de logs, mas
não tem porque nós explicarmos ela aqui, isso é tarefa pra um capítumo sobre
administração do sistema FreeBSD, pro nosso caso de Firewall específico a seguinte
entrada deve ser o bastante:
Uma vez que tudo esteja pronto pra utilizar as funções de logs do
ipfirewall(4), vamos começar a definir quais regras nós queremos logar quando elas forem
filtradas. Existem dois parâmetros básicos pra usarmos em conjunto com nossas regras
pra definirmos que queremos logar *aquela* regra. Vejamos:
"log" – É o parâmetro mais comum. Toda vez que uma regra que for definida
o "log" for acionada, então a ação definida ("action") por aquela regra será logada todas as
vezes que um pacote coincidir a regra. Por isso tome muito cuidado pra não defnir "log"
pra uma regra que a terão pacotes frequentementes assimilados a ela, como por exemplo:
Essa é uma regra que permite todo o tráfego de todos os tipos de pacotes de
todas as redes pra todas as redes, então imagine a frequência de informações que serão
logadas sempre que cada pacote for permitido pelo seu firewall. Esse tipo de regra pode
facilmente proporcionar problemas pro seu disco local ;-)
Por outro lado, definir "log" pra uma regra geral de negação é uma pedida
considerável:
add 65000 deny log all from any to any
Essa regra é mais considerável, porque é uma das últimas, em uma política
clara de firewall do tipo "CLOSED" ou seja, tudo que deve ser permitido já o foi nas regras
anteriores que suponhamos existir, portanto nos interessa manter logs das conexões
negadas. Além do que o número da regra é 6500, o que, em relação à regra anterior (500)
é muito mais seletiva, visto que é uma das últimas regras a serem checadas. Preste muita
atenção pra escolher quais regras você quer logar e quais você não quer.
Sempre que uma regra é logada, as informações geradas pra tal pacote são:
Por definição, uma regra de firewall sua, quando logada, deve parecer com o
seguinte:
Vamos assumir que estamos usando uma política de firewall fechado (ou
seja, firewall_type no /etc/rc.conf não está definido como "OPEN" e não existe a entrada
IPFIREWALL_DEFAULT_TO_ACCEPT no kernel do sistema). Nesse caso, as duas regras
anteriores vão permitir o roteamento dos pacotes desejados. A regra número 1000 vai
permitir todos os pacotes que sejam parte de uma conexão TCP já estabelecida, e então a
verificação das regras subsequentes vai cessar para aqueles pacotes. Se, por outro lado
algum pacote não fizer parte de uma conexão iniciada, a regra 1000 não será assumida, e
então a verificação passa pra regra seguinte. Na regra número 2000, se o pacote for do
tipo TCP SYN, e for destinado à porta 22 (serviço SSH), a regra vai permitir que ele seja
roteado. Nesse caso, pacotes TCP SYN iniciam uma conexão TCP, por isso a importância
de deixa-los passar. Os pacotes subsequentes relacionados ao serviço SSH serão
permitidos pela regra 1000, já que eles farão parte de uma conexão já estabelecida. Você
pode experimentar uma configuração parecida usando 'stateless':
Vamos analizar um caso especial: FTP. Se você fosse fazer um firewall cujas
regras fossem exclusivamente 'stateless', você teria que manter todas as portas entre a
1024 e a 65000 abertas. O motivo é simples, o protocolo FTP é um protocolo revoltadinho
que estabelece suas conexões em qualquer porta não reservada, ou seja qualquer porta
acima da 1024. Uma solução não muito prática é liberar as portas 21 e 22 de forma
'stateless' e forçar seus clientes FTP a estabelecerem conexões exclusivamente não-
passivas (FTP Modo Passivo). O problema é que nem todos os seus clientes (como os que
usam Windows por exemplo) tem muita noção de FTP a ponto de coloca-lo em modo nãp-
passivo, por mais simples que isso seja. Nesse caso, portanto, permitimos a inicialização
de uma conexão na porta 21 (onde todas as requisições FTP iniciam) e posteriormente
permitimos o roteamento de pacotes pertencentes à essa conexão por qualquer porta
(utilizando "stablished"). Essa é a forma mais eficiente de se controlar FTP via firewall, e
essa prática pode ser adotada pra outros serviços que tenham comportamente similar a
esse.
- Protocolo
- Endereço & Porta IP
- Destino & Porta IP
- Tempo da regra esgotado
A primeira variável do sysctl(8) indica que o tempo de vida padrão pra cada
regra dinâmica que use um pacote do tipo TCP ACK é 300 segundos. A variável seguinte
indica que o tempo de vida de uma regra dinâmica cujo pacote seja TCP SYN é 20
segundos. Na regra seguinte, 20 segundos também de vida pra regras com pacotes TCP
FIN. Depois 5 segundos de vida pras regras que encontrarem pacotes do tipo TCP RST ou
outros pacotes (UDP, ICMP, etc), conforme indica as duas últimas variáveis do sysctl(8).
8) – A regra seguinte (2000) verifica que o pacote não é do tipo TCP SYN,
então não define regra dinâmica praquele pacote.
No nosso primeiro exemplo de regra 'stateful' esse pacote spoofado teria sido
aceito, porque a regra que continha "established" como dependência teria sido cumprida,
pois aceitava todo pacote com um destino em particular, que tivesse ao menos a 'flag'
ACK definida, e o pacote Spoofado cumpriria esse critério. Já a regra dinâmica criada
exclusivamente para as duas pontas em comunicação, verificou pela porta de origem e
consequente resposta da conexão, informação que é gerada aleatóriamente, ou seja, não
existe uma forma lógica de se manipular. Esses são exemplos e rasões primários, contudo
poderosos em relação à vantagens das operações avançadas de 'stateful' do ipfirewall(4).
Esse tipo de vantagem o IPFilter também possui.
Pacotes TCP SYN spoofados são usados com muita frequência em taques de
rede. A ação mais comum desse tipo de ataque consiste em enviar inúmeros pacotes TCP
SYN (SYN FLOODs) pra uma determinada estação na rede, de modo que toda a conexão
fique em estado de espera, por estarem esperando suas respostas em fila. Dessa forma o
tráfego de rede controlado pelo kernel fica saturado, evitando o roteamento de novas
conexões legítimas. Mesmo considerando que o Stack TCP/IP do FreeBSD é desenvolvido
de forma à eliminar randomicamente conexões TCP que estiverem em fila de espera de
forma inativa, esse tipo de ataque pode ser devastador dependendo da política de
eliminação das filas adotado no sistema (via sysctl(8)) e dependendo também da largura
de banda da rede. Vamos assumir que, se os pacotes TCP SYN chegarem ao servidor de
forma muito rápida, eles vão fazer pedidos falsos de conexões de forma mais rápida do
que eles podem ser eliminados da fila, não sobrando recursos o suficiente pra tratarmos
todas as conexões legítimas que também estiverem chegando.
net.inet.ip.fw.dyn_count
Dessa forma só os pacotes TCP SYN que saírem pelo seu firewall poderão
ser roteados, ou seja, os pedidos que entrarem serão automaticamente negados. Esse é o
mesmo tipo de proteção que o NAT e proxies transparentes de forma geral oferecem pras
máquinas internas.
Já podemos entender facilmente essa regra, que cria uma regra dinâmica
pra cada pedido de echo que nossas estações internas façam pra fora. Quando a resposta
chega ela é permitida pela regra dinâmica que estabeleceu a conexão entre as duas
pontas, e se alguém de fora tenta pingar uma máquina interna, a regra padrão nega essa
ação. O protocolo ICMP usa a variável net.inet.ip.fw.dyn_short_lifetime do sysctl(8). Se a
resposta do ping demorar mais que 5 segundos pra chegar a regra vai ser descarregada e
o pacote não vai poder ser roteado. Se você considera que as respostas de ping levarão
mais que 5 segundos pra acontecer, então você, como administrador da rede deve elevar o
valor da variável no sysctl(8). De qualquer forma a maioria dos atrasos de rede levam
menos de 1 segundo, a não ser que seja IRC ;-)
A regra 2000 ainda poderia ter definido uma faixa de rede com permissão
pra fazer o ping, caso existisse mais de uma rede por trás do firewall, e apenas uma delas
poderiam pingar máquinas externas. Na verdade escolhemos a regra assim porque é a
forma que mais se aproxima do nosso exemplo inicial de controle do ping.
Vamos dar uma olhada na saída que você devei encontrar quando listar as
regras dinâmicas de um firewall 'stateful' no seu FreeBSD:
Mesmos depois que uma regra dinâmica foi descarregada, você ainda pode
lista-la com o comando "ipfw list", contudo a regra inativa vai ter um valor de tempo de
vida ("T") igual a zero (T 0, #). Uma vez descarregada, a regra não vai mais aceitar pacotes,
simplesmente porque ela não existe mais, até que a mesma regra seja reiniciada, ou
ressucitada pela mesma entrada "keep-state" da regra que a originou inicialmente. Uma
vez descarregadas, as regras também podem ser substituídas por novas regras
dinâmicamente ativadas. A não ser que todas as regras dinâmicas continuem em pleno
uso, elas serão continuamente substituídas por novas regras, especialmente se o número
de regras dinâmicas alcançou o máximo permitido pelas variáveis do sysctl(8).
Não vamos comentar a listagem acima, cabe a você entender o que está
acontecendo com o firewall. Note que existe conexões cujo tempo de vida já se esgotou, e
ainda assim a mesma foi listada.
Bom, quando você começar usar regras 'stateful' em grande escala, você vai
perceber o quanto a saída de um comando pra listar as regras do ipfw(8) vão se tornar
perturbadoras, devido ao enorme número de regras dinâmicas criadas. O ipfw(8) lista
todas as regras dinâmicas, mesmo que já descarregadas pra oferecer controle total do
firewall ao administrador, contudo nem sempre você quer analisar as regras dinâmicas, e
apenas as estáticas, já que são essas que criam as dinâmicas. Nesse caso uma solução
óbvia do mundo Unix seria:
Por exemplo, se nós quisermos restringir 20% dos pedidos de echo (echo
requests) do ICMP, poderíamos usar a seguinte regra:
add 1000 prob 0.8 allow icmp from any to any in icmptypes 8
Podemos também querer negar 50% dos pacotes TCP SYN pro servidor web,
dessa forma simulando um tráfego pesado na interface ep0. Faríamos da seguinte forma:
add 1000 prob 0.5 allow tcp from any to any in setup via ep0
7.2. Dummynet;
options DUMMYNET
Depois de compilado o nosso kernel com mais essa opção (além das opções
típicas do ipfirewall(4)), o administrador do sistema vai poder especificar a criação de
túneis (chamados "pipes") pra controle do tráfego. Um túnel nada mais é do que uma
regra de Traffic Shapping que controla o roteamento, canalizando as informações que
posteriormente irão trafegar por endereços específicos de rede. A criação desses túneis é
feita com o comando "pipe" do ipfw(8). O tráfego é redirecionado à esses tuneis por meio
do comando "pipe <pipe #>" no ipfw(8). Vamos então criar um túnel simples:
Note que, assim como nas regras de firewall, o "pipe" é apenas mais uma
ação pro ipfw(8), exatamente como "add" ou "delete", portanto antes de cada comando é
feita uma chamada ao ipfw(8) (/sbin/ipfw pipe 10... por exemplo).
Esse túnel simples que criamos logo acima vai limitar o fluxo de
informações pra uma velocidade máxima de 100 Kilobits por segundo. Existem várias
maneiras distintas de indicarmos as medidas de velocidade de tráfego: bit/s, Byte/s,
Kbit/s, Kbyte/s, Mbit/s, Mbyte/s. Cada túnel de limitação de banda deve usar a opção
"bw" (de bandwidth – banda).
Uma outra maneira de controlar tráfego é usar a opção "delay" que força um
atraso na comunicação, simulando o que se conhece como "lag" do sistema:
O valor que segue a opção "delay" é o tempo de atraso que nós desejamos,
definido em milisegundos. Nesse exemplo todo o tráfego roteado através desse túnel terá
um atraso de 100ms.
"plr" significa "packet loss rate" (taxa de perca de pacotes), portanto o valor
indica à que taxa os pacotes não serão roteados, oposto da opção "prob" do ipfw(8), que
indica a taxa dos pacotes que serão roteados. Pra evitar qualquer confusão com a
utilização de "prob" ou ®plr", aconselhamos que o administrador assuma uma escolha
pessoal entre as duas possibilidades. Ambas são igualmente efetivas, e co-existem porque
a primeira é nativa do ipfirewall(4) enquanto a segunda faz parte do dummynet(4).
... mas não vamos definir uma MTU menor pra device, com o ifconfig(8),
nem vamos diminuir o tamanho da fila (queue), que seria nossa melhor opção. A fila pros
pacotes então seria 1500 bytes (12000 bits) x 50, ou seja, 600Kbits de fila. Pra um túnel
que esta limitando a banda à 56Kbit por segundo, levaria aproximadamente 10.7
segundos pra uma fila de 600Kbit ser preenchida. Esse é um atraso inaceitável pra por o
tráfego em andamento. Pra evitar esse tipo de problema é recomendável ajustar
manualmente o tamanho das filas (queue), em 'slots' que é mais fácil pra uma
comparação com o padrão (que sabemos ser 50) ou em ®Kbits" que é uma melhor
atribuição à quantidade de dados. A segunda opção é a melhor, porque além de ser um
valor mais compreensível, o uso de 'slots' requer que o administrador também defina o
valor pra MTU da interface, utilizando o ifconfig(8), já que esse valor equivale à variável de
multiplicação no tamanho da queue (fila). Lembre-se, quanto menor a banda disponível,
menor deve ser a fila. No nosso exemplo acima, uma configuração rasoável pra fila seria:
Uma poderosa característica dos túneis é permitir múltiplas filas por fluxo.
Por exemplo, imagine que você tenha várias máquinas atrás do seu firewall, e você quer
limitar a banda pra 100Kbits/s pra cada máquina, ou seja, não vai agregar um valor
somatório à banda pra todas as máquinas, vai definir individualmente a banda. Existem
duas formas de se fazer isso, a mais óbvia e primeira conclusão que um administrador
tomaria seria criar túneis e regras individuais pra cada máquina, com o ipfw(8). Mas
agora considere que você pode definir máscaras pra identificar um subconjunto de
estações que pertencem ao mesmo túnel, exatamente como netmasks e bitmasks
identificam subconjuntos de estações que pertencem a mesma rede.
"dst-ip" – máscara pro IP de destino do pacote que esta sendo enviado pelo
túnel.
"src-ip" – máscara da origem
"dst-port" – máscara da porta de destino
"src-port" – máscara pra porta de origem
"proto" – máscara do protocolo
"all" - máscara geral, que especifica todos os bits nos campos (dst-ip, src-ip,
etc) como importantes e válidos.
Por exemplo, vamos assumir a mesma idéia anterior de uma rede atrás de
um firewall onde cada estação deve ter uma banda de 100Kbit/s. Se nós simplesmente
direcionarmos todo o tráfego pra um túnel, o valor do tráfego será a somatória de todas as
estações, e não valores individuais. Pra utilizar máscaras pras estações às quais o tráfego
deve ser separado por filas específicas, dessa maneira limitando a banda de forma
separada, faremos o seguinte:
Existem dois motivos pra termos túneis pra entrada e pra saída do tráfego,
mas uma delas nós vamos discutir posteriormente. A primeira questão que deve nos
prender atenção no momento é que cada túnel define uma máscara diferente. O túnel 10
define a máscara 0x000000ff pros endereços de origem, simplesmente porque a regra
1000 direciona todo o tráfego que sai (out) pela rede interna, ou seja a máscara *deve*
fazer menção ao endereço de origem, porque cada origem faz diferença quando queremos
filas distintas pra cada estação que origina o fluxo. Da mesma forma o tráfego que está
chegando (in) deve ser separado em filas (queue) disntas de acordo com cada endereço de
destino.
net.inet.ip.fw.one_pass: 1
add 1000 deny icmp from any to 12.18.123.0/24 in via xl0 icmptypes 8
add 1010 allow icmp from 12.18.123.0/24 to any out via xl0
icmptypes 8
add 1020 allow icmp from any to 12.18.123.0/24 in via xl0
icmtypes 0
R)