DNS  e "The djb Way"

Wayne Marshall <[email protected]>

Fácil Serviço de Nomes no FreeBSD com djbdns

O que está em um nome? Aquilo é o propósito completo do DNS, o Serviço de Nome de Domínio, para responder apenas a essa pergunta. Dado algum hostname arbitrário em qualquer lugar na Internet, encontra seu endereço IP (ou o endereço de seu servidor de e-mail, servidor de nome de domínio, etc.) E, menos frequentemente, o reverso: dado um endereço IP, encontra o domain/hostname associado. O DNS é possívelmente a maior e mais sucedida implementação de um sistema de banco de dados distribuído. Melhor que um único repositório enorme de banco de dados de hostname, o banco de dados DNS é dispersado entre milhares, talvez milhões, de sistemas cooperando, cada um responsável por responder ao subconjunto das perguntas especificamente dentro de sua autoridade. A maioria dos sistemas Un*x em geral, e sistemas BSD em particular, executam alguma versão ou outra do BIND, o "Berkeley Internet Name Daemon", para fazer este serviço. Para muitos, embora, BIND é um bane--considerado buggy, inseguro, difícil de configurar, fácil de screw up. E quando o BIND vai mau, é como se as redes simplesmente parassem de existir.

Assim então o que está no nome: djbdns? Para uma coisa, um bocado de consoantes, suplicando por uma vogal. Como estamos supondo dizer isto em voz alta, de qualquer modo? Entretanto, o djbdns é o pacote de servidores DNS e utilitários do Daniel J. Bernstein, e uma alternativa digna ao BIND. O Bernstein é o melhor conhecido como o autor do qmail, assim bem como um número de outros utilitários de infraestrutura com uma reputação a segurança proeminente, a confiabilidade e o alta-performance.

Seguindo o que pode ser chamado o "the djb way", como exemplificado pelo qmail, djbdns é um sistema compacto, coersivo e modular, com um número pequeno de componentes de construído-com-propósito de cada um projetado fazer seu trabalho particular seguramente, confiavelmente, e rápido. Isto o faz fácil de instalar somente aqueles serviços de DNS necessários para um host particular ou rede, enquanto limita a exposição do sistema as vulnerabilidades potenciais de um monolitico, faz-tudo alternativa como BIND's "named".

Por example, seu laptop FreeBSD conectado a Internet pode ser instalado com um DNS cache simples e efetivo. Isto eficientemente acumula respostas de um servidor de nomes do repositório local, ao invés de gerar tráfego de rede extra ao seu servidor de nome do ISP. Similarmente, um único servidor em sua rede local pode ser usado para cache e compartilhar procuras de nome de domínio para todos clientes naquela rede. E se você quer publicar informação de DNS você mesmo, o djbdns pode fornecer para aqueles tão bem, indolormente servindo nomes para todos os hosts em uma rede privada ou pública.

Este artigo considerará uns poucos cenários e demonstrará a fácil instalação e configuração do djbdns no FreeBSD. Nós também aproveitamos uma brecha para espiarmos o "the djb way", um universo paralelo alternativo de fazer coisas no Un*x. A primeira vista é estranho e assustador, mas depois de um tempo "the djb way" pode até começar fazer senso (e que pode ser assustador, também!)

Instalação

Uma característica essencial do "the djb way" é construir do fonte; você normalmente não encontrará quaisquer pacotes pré-compilados. Felizmente, assim como todos códigos do Bernstein, djbdns é genérico, não-proprietário, unadorned C, e construirá bem segindo suas próprias instruções de instalação somente sobre quaisquer sistema Un*x a fora.

Mas o djbdns é tambem bom caso para tirar vantagens do sistema ports do FreeBSD. Não somente o port do djbdns buscará, patch, construirá, instalará, e registrará no sistema, ele irá também pegará e instalará uma coleção de páginas do man para concordar; caso contráro estes não são incluídos com a distribuição do fonte do Bernstein. Para se beneficiar dessas vantagens, ilustraremos a instalação com o sistema ports do FreeBSD.

Primeiro, se você não tem já pronto, instale o pacote pré-requisito "daemontools", também do Bernstein. A construção do ports do djbdns fará as dependências, mas veja também o Apêndice deste artigo para mais informação de instalação e configuração do pacote daemontools.

A construção e instalação o djbdns esta tão simples quanto fazer os seguintes comandos como root:

	# cd /usr/ports/net/djbdns
# make
# make install
Depois da instação execute para complementação, adicione os seguintes grupos e usuários ao sistema:
	# pw groupadd nofiles -g 800
# pw useradd dnslog -g nofiles -u 810 -d /nonexistent -s /sbin/nologin
# pw useradd dnscache -g nofiles -u 811 -d /nonexistent -s /sbin/nologin
# pw useradd tinydns -g nofiles -u 812 -d /nonexistent -s /sbin/nologin
Para otimizar a segurança, os componentes do djbdns executará sobre estas contas de usuários despriveligiados. Sinta-se livre, naturalmente, para designar numeros uid/gid de sua escolha.

That's it! Agora o djbdns está pronto para rodar. Tudo que nós precisamos fazer é decidir como nós gostariamos de usá-lo.

Configurando um DNS cache local

Considere um serviço de nome de domino possa ser segregado entre duas funções separadas. Uma, que pode ser chamada "resolver", é responsável por realizar procuras hostname/addresses entre banco de dados do DNS distribuídos sobre a Internet. A segunda função, que pode ser chamada "publisher", é responsável pelo fornecimento de dados DNS associado com um específico conjunto de hostnames/addresses.

Mais simplificadamente, a parte resolver de um sistema DNS faz as perguntas, enquanto a parte publisher do sistema responde aquelas perguntas.

No pacote djbdns, o resolver é chamado "dnscache". No pedido de programas clientes, tais como seu web browser ou agente de transporte de correio (mta), o dnscache fará resolução de hostname/address recursivas perguntas entre servidores de nomes autorizados na Internet. Para eficiência, o dnscache então armazena todas as responstas obtendo no cache de memória local, assim que futuras perguntas podem ser respondidas rapidamente, e sem duplicamento do tráfego da rede por perguntas posteriores.

Um dos usos mais fáceis e mais efetivo do djbdns, então, é para instalar somente como um DNS cache em sua estação de trabalho. Por exemplo, ao invés de indicar seu laptop FreeBSD no servidor de nomes na rede de seu ISP, você pode executar dnscache e se beneficiar de construir um cache de hostname/addresses na sua própria máquina.

Such a configuração não é simples -duh. Como root, execute os seguintes comandos:

	# dnscache-conf dnscache dnslog /etc/dnscache 127.0.0.1
# ln -s /etc/dnscache /var/service
# echo 'nameserver 127.0.0.1' >/etc/resolv.conf
Parabens! Em poucos segundos o dnscache será iniciado pelo daemontools, e todas pergutas DNS de sua estação de trabalho agora será feita pelo dnscache. Para ver isto em opereção, você pode usar o nslookup como sempre:
	# nslookup - 127.0.0.1
Default Server: localhost
Address: 127.0.0.1

> www.freebsd.org
Name: www.freebsd.org
Address: 216.136.204.117
Dependendo da velocidade de sua conecção de rede, o primeiro lookup do website do FreeBSD pode levar poucos segundos para retornar uma resposta. Quando você repete a pergunta, no entanto, a resposta aparecerá instantanea, desde que ele está agora armazenado no seu cache local.

O que está acontecendo com os passos da configuração descritos acima? O comando "dnscache-conf" automatiza a instalação de executar scripts para o daemontools, e tem quatro argumentos: o nome do usuário do binário do dnscache que executará sob (dnscache), o nome do usuário que logger executará sob (dnslog), a configuração do dnscache e diretório do log (/etc/dnscache), e o endereço IP que o dnscache amarrará ao (127.0.0.1).

O próximo comando linka o diretório de configuração do dnscache só para criado pelo dnscache-conf, ao diretório de spool do serviço daemontools, /var/service. Agora o dnscache irá executar sob o controle do daemontools, com todos os utilitários disponíveis para iniciar, parar, suspender, e verificar o status do serviço que o daemontools fornece.

Finalmente, colocando o endereço localhost no "/etc/resolv.conf" indica que programas cliente ao dnscache resolver em sua estaço de trabalho. Todas perguntas procuradas pedidas pelo seu navegador web, cliente ftp, e assim por diante, agora serão feitas pelo seu próprio dnscache.

Configurando um cache DNS compartlhado para um rede local

Ter seu próprio dnscache pessoal é legal, e ótimo modo para iniciar com o pacote djbdns. Mas tão logo que você pode querer compartilhar um cache DNS entre várias máquinas em uma rede. Por exemplo, considere uma rede local protegida pelo firewall que inclui um numero de servidores e clientes Windows. Fornecendo um DNS cache comum nesta rede, você pode aumentará a velocidade das perguntas para todos seus clientes locais, significativamente reduzir o tráfego DNS atravessando o gateway.

Configuração é quase tão fácil como o primeiro exemplo. Aqui nós assumeremos que você executará o dnscache em seu servidor FreeBSD com um o endereço de rede local de 10.0.1.53. Os seguintes comandos instalará-lo:

	# dnscache-conf dnscache dnslog /etc/dnscache 10.0.1.53
# touch /etc/dnscache/root/ip/10.0.1
# ln -s /etc/dnscache /var/service
Agora todos clientes hosts na rede podem ser configurados com uma entrada ao "/etc/resolv.conf" (ou equivalente) de:
	nameserver 10.0.1.53 
O dnscache executando nesta máquina então resolverá todas perguntas hostname/address que eles recebe da rede 10.0.1.0/24, acumulando o resultado para todos compartilhar. Note que a única diferença entre esta instalação e a anterior, outra que o endereço IP que nós estamos usando para o servidor dnscache, é que capacita o dnscache para responder a perguntas de qualquer host na rede 10.0.1.0/24. Aquilo é o que o arquivo vazio criado pelo comando "touch" capacita. Caso contrário, por padrão, o dnscache não aceitará perguntas de hosts remotos.

O tamanho do cache usado pelo dnscache é configurável. Por padrão, ele é um milhão de bytes. Para aumentá-lo para, digamos, 32 milhões de bytes, faça o seguinte:

	# echo 32000000 > /etc/dnscache/env/CACHESIZE
# echo 34000000 > /etc/dnscache/env/DATALIMIT
# svc -t /var/service/dnscache
O segundo comando não é um erro de digitação; DATALIMIT é normalmente definido para algo maior que CACHESIZE. O último comando então usa o daemontools "svc" utilidade para reiniciar o processo do dnscache. O cache agora conterá acima de 32 megs de procuras DNS, antes descarga das maiorias das perguntas velhas. Procuras ativas voarão, e seus usuários apreciarão como seus navegadores agora conectam mais rápido que comumente sites favoritos.

Configurando o cache DNS com um Servidor de Nomes privado para uma rede local

A configuração acima usa o dnscache para perguntar servidores de nomes existentes na Internet para resolver procurars de hostname/address. Isto é ótimo para endereços acessíveis publicamente, mas não faz muito bem para procurar hostnames em sua própria rede local. Para pequenas redes simples, você pode usar um simples recurso copiar o arquivo comum "/etc/hosts" para todos os hosts na rede. Mas agora que você tem acesso ao djbdns e este bom artigo, você provavelmente querá instalar um genuíno servidor de nome para sua rede local ao invés.

O componente "publisher" do pacote djbdns é chamado tinydns. O "tiny" neste nome não deve ser levado como uma indicação de suas capacidades ou performace, mas em relação ao seu tamanho e consumação de recursos. Na verdade, o tinydns é bastante poderoso. O Bernstein cita o caso de duas companhias de hosting de domínios usando o tinydns que juntas constituiam acima meio milhão de endereços na Internet!

A configuração descrita aqui construirá no cache DNS externo configuration executando no host 10.0.1.53 descrito acima. Mas nós agora adicionaremos o tinydns a este sistema, usando um endereço loopback privado de 127.53.0.1. Para fazer isto o endereço IP disponível para o tinydns, edite "/etc/rc.conf" e adicione a seguinte linha:

	ifconfig_lo0_alias0="inet 127.53.0.1 netmask 0xffffffff"
Reinicie e digite "netstat -rn" para certificar-se que o novo endereço IP está na tabela de roteamento. Então continue com a configuração do tinydns como segue:
	# tinydns-conf tinydns dnslog /etc/tinydns 127.53.0.1
# ln -s /etc/tinydns /var/service
O primeiro comando, "tinydns-conf", automatiza o instalação do tinydns executa scripts para o daemontools. Como "dnscache-conf", o comando tem 4 argumentos: o nome de usuário do binário tinydns executará sob (tinydns), o nome de usuário do logger (dnslog), a configuração do tinydns e diretório do log (/etc/tinydns), e o endereço IP que o tinydns ligará ao (127.53.0.1).

Próximo, configure o dnscache para procurar direto a informação ao domínio local para este servidor tinydns privado:

	# echo '127.53.0.1' > /etc/dnscache/root/servers/example.org
# echo '127.53.0.1' > /etc/dnscache/root/servers/1.0.10.in-addr.arpa
Este passo é a mágica crucial, disponibilizando o "glue" que conecta o dnscache a seu tinydns privado. Agore quando o dnscache recebe um pergunta para um endereço local "example.org", ele pedirá a informação do servidor tinydns executando no endereço loopback privado de 127.53.0.1.

O próximo passo é carregar a base de dados do tinydns local com a informação do hostname para a rede local example.org:

	# cd /etc/tinydns/root
# ./add-ns example.org 127.53.0.1
# ./add-ns 1.0.10.in-addr.arpa 127.53.0.1
# ./add-host dagwood.example.org 10.0.1.53
# ./add-host blondie.example.org 10.0.1.1
# ./add-alias mailhub.example.org 10.0.1.1
# ./add-host dithers.example.org 10.0.1.254
# ./add-alias bastion.example.org 10.0.1.254
# make

Isto constroi um base de dados cdb no diretório /etc/tinydns/root, com o nome de arquivo "data.cdb". ("cdb" é o sistema de base de dados hashing do Bernstein para rápido-acesso, arquivos do banco de dados constante; um subconjunto do completo pacote "cdb" está incluido com ambos fontes daemontools e djbdns.) Uma versão editável deste banco de dados também existe no arquivo chamado "data", e está fácil para modificar diretamente com qualquer editor de texto. Executando "make" no diretório "/etc/tinydns/root" então converte a versão texto-explicito do banco de dados dentro do formato cdb, usando o utilitário tinydns-data(8).

Agora reinicie o dnscache (uma boa idéia para reiniciar o cache depois de quaisquer atualizações ao banco de dados do tinydns local, em ordem para retirar quaisquer perguntas falhas que deve agora suceder):

	# svc -t /var/service/dnscache
Veja se nós estamos conseguindo:
	# nslookup - 10.0.1.53
Default Server: dagwood.example.org
Address: 10.0.1.53

> blondie
Non-authoritative answer:
Name: blondie.example.org
Address: 10.0.1.1
Sim! Nós agora temos um servidor de nomes caching aquelas repostas das perguntas a Internet hosts e hosts em nossa rede privada. Hosts na simples rede local precisa de um "/etc/resolv.conf" (ou equivalente) que contém:
	domain example.org
nameserver 10.0.1.53
Se você está executando um servidor dhcpd na sua rede, este arquivo de configuração incluirá o seguinte:
	option domain-name "example.org";
option domain-name-servers 10.0.1.53;
Vá em frente agora e adicione hostnames para todos aqueles hosts locais Windows dentro de ambos sua configurações tinydns e dhcpd. Então quando você loga ao seu servidor e verifica
	# arp -a
você verá, agora com hostnames, uma lista de todas as máquinas atualmente gerando tráfego da sua rede. Como conveniente!

Administração

Como maioria das coisas "djb", os utilitários djbdns não necessita muito no modo de intervenção e ter muita administração. Uma vez eles estão instalados, eles somente executam.

Embora dnscache/tinydns funcione bem com o os clientes DNS padrões, como nslookup(8) e dig(1), djbdns também instala sua própria ferramenta de pergunta bem como: dnsip, dnsipq, dnsname, dnsmx, dnstxt, dnsqr, dnsq, e dnstrace. Os utilitários dnsip(1), dnsipq(1), e dnsname(1) são particulamente úteis para chamadas do shell scripts. Para debugging e verificação sua instalação, você pode usar:

	$ dnsqr any dithers.example.org
Isto usará o servidor de nomes dnscache padrão (como especificado no /etc/resolv.conf) para procurar quaisquer registros de DNS para o host "dithers" na rede local example.org. Se logged em ao "dagwood", onde nós instalaremos o servidor tinydns local, nós podemos perguntar ao tinydns diretamente com:
	$ dnsq any blondie.example.org  127.53.0.1
Crie o primeiro poucas entradas no banco de dados tinydns usando os utilitários ./add-ns e ./add-host descritos acima. Isto te dará um poucas entradas template no arquivo "dados" texto-explicito para você iniciar. O sistema também inclui o utilitário tinydns-edit(8) para manutenção dos dados do DNS, mas eu escontro ele simples para editar "dados" diretamente em um editor de texto; veja a manpage tinydns-data(8) para informação considerando o formato registro . Na verdade, você necessitará para editar o arquivo "dados" diretamente quando que você quer remover uma entrada, desde que entretanto não haja utilitários fornecidos para apagar. Somente lembre-se de executar "make" ou "tinydns-data" no diretório depois de fazer quaisquer alterações ao "dado". Isto testará as entradas por sintaxe e lógica e pô-las ao arquivo "data.cdb"; as mudanças ao tinydns então terão efeito imediato.

Para facilmente manter grande banco de dados de DNS, você não deve ter que perguntar se há quaisquer soluções para uso de SQL com o tinydns. Naturalmente há vários, incluindo PostgreSQL e MySQL. Veja a referência "Life with djbdns" para indicações.

Periodicamente, você pode olhar os logs. Se instalado como acima, monitore o dnscache log com:

	# tail -f /etc/dnscache/log/main/current
Para fazer timestamps mais significativo, pipe o log através do utilitário "tai64nlocal":
	# tail -f </etc/dnscache/log/main/current | tai64nlocal
Similarmente, monitore o tinydns log com:
	# tail -f </etc/tinydns/log/main/current | tai64nlocal
Alguns administradores podem preferir consistencia de manter todos logs em /var/log. Para instalar o dnscache para logar em /var/log/dnscache, por exemplo, primeiro faça o diretório:
	# mkdir /var/log/dnscache
# chown dnslog:nofiles /var/log/dnscache
# chmod 1755 /var/log/dnscache
Então mude o script /etc/dnscache/log/run criado pelo dnscache-conf para:
	#!/bin/sh
exec setuidgid dnslog multilog t /var/log/dnscache
Se svscan está já executando, mate o serviço para as mudanças no script executável para fazer efeito:
	# svc -k /var/service/dnscache/log
Então faça uma pergunta DNS e verifique que o resulta estão agora sendo logados ao novo arquivo "/var/log/dnscache/current".

Como para a organização de sua hierarquia do sistema de arquivos, você pode ter suas próprias opiniões sobre a instalação do desenho descrito nos exemplos. Bem okay, então. Outros comuns desenhos incluem instalação sob paths "/usr/local/etc" ou "/var", o anterior sendo a maioria comumente "FreeBSD way". Colecionando todos as configurações djbdns sob um comum diretório "./dns" ou "./djbdns" é também um modo razoável de organizar as coisas. Então você deve usar "/usr/local/etc/djbdns/dnscache" e "/usr/local/etc/djbdns/tinydns" para seus diretórios de instalação nos exemplos acima.

Para conveniência administrativa, é útil ter um simples script de controle do daemontools para seus serviços djbdns. Crie um arquivo chamado "dnsctl" que pareça algo como o seguinte, coloque-o em um path executável e chmod para, digamos, 750:

	#!/bin/sh
# file /usr/local/bin/dnsctl
# daemontools control script for djbdns services
# wcm, 2002.08.26 - 2002.08.26
# ===

SERVICES="/var/service/dnscache /var/service/dnscache/log \
/var/service/tinydns /var/service/tinydns/log"

case "$1" in
start)
echo "Starting djbdns services"
svc -u ${SERVICES}
;;
stop)
echo "Stopping djbdns services"
svc -d ${SERVICES}
;;
restart)
echo "Restarting djbdns services"
svc -t ${SERVICES}
;;
status)
svstat ${SERVICES}
;;
cdb)
echo "Updating tinydns data"
cd /var/service/tinydns/root; tinydns-data
;;
help)
cat << HELP
start -- start up djbdns services
stop -- stop djbdns services
restart -- restart djbdns services
status -- view current status of djbdns services
help -- this screen
HELP
;;
*)
echo "Usage: $0 [start|stop|restart|status|help]"
exit 1
;;
esac

exit 0

### that's all, folks!
Agora você pode executar:
	# dnsctl status
e veja um relatório do uptime e status dos serviços instalados do djbdns. Ou:
	# dnsctl cdb
para reconstruir o arquivo do banco de dados do tinydns.

Aquilo sobre: executando o djbdns é de outra maneira não muito suado ou excitante. Mas realmente, não é aquilo que você sempre quis em um servidor de nomes?

Conclusões

Pelo uso do djbdns e a coleção de ports do FreeBSD, nós fizemos um rápido trabalho de instalação de servidor de nomes em uma única estação de trabalho e redes locais. Estes fazem boas plataformas para divertir-se com DNS, e para testar diferentes configurações para encontrar a instalação que melhor se adapta ao seu propósito.

O próximo passo na progressão das coisas é going public: setting up um couple de servidores de nomes (primário e backup) para responder diretamente a perguntas da Internet para seus hosts endereçavel publicamente. Fazendo isto não é muito mais difícil que instalar o tinydns como descrito acima, exceto que você agora estará servindo endereço de IP pública de um host endereçavel da Internet (melhor que o endereço loopback privado que nós usamos acima.) Para instruções específicas em fazer isto corretamente, por favor familiarize-se com a documentação adicional descrita na seção "Referências". Depois que seus novos servidores de nomes instalados e minuciosamente testados, você então coordenará com seu provedor upstream (rio acima). Eles adicionarão novos NS records ao seus prórprios servidores de nomes, delegando autoridade de serviço de nome para seu domínio abaixo para você.

O pacote djbdns é feature-full e oferece muitas outros utilitários e serviços não descritos aqui. Estes permitem grandes sites instalarem e transferirem zonas, balanceamento de carga among muitos servidores de nomes, e fornecer segurança adicional em redes públicas protegidas por firewall. Such capabilities faz o djbdns completamente escalavel, de única estação de trabalho e pequena rede local descrita neste artigo, aos maiores provedores de serviço de rede em operação hoje.

De qualquer modo você usa o djbdns, você está certo para procurá-lo seguro, confiável, rápido, e livre de problemas. Como o tempo passa, você pode até encontrar você mesmo começar apreciar "the djb way". E se o djbdns não te deixou completamente que longe, bem, ao menos ele te ajudou sair de um amarra.

Apêndice: Instalando o daemontools

O pacote daemontools do Bernstein fornece um conjunto de utilitários para instalação, log e daemons de administrar servidores, como djbdns e qmail, facilmente e seguramente. Com os utilitários daemontools e Bernstein's ucspi-tcp (não discutidos aqui), ele é possivel instalar só sobre qualquer servidor, e facilmente criar serviços customizados, sob uma consistente e seguro mecanismo de controle, sem uso do inetd, rc.local, e/ou outros varios métodos de script de inialização e execução.

Assim com o djbdns, o sistema ports do FreeBSDpode ser usado para tirar vantagens com daemontools. Por exemplo, com o FreeBSD 4.6, os seguintes comandos irá buscar, patch, construir, instalar e registrar o daemontools-0.76, incluindo a conversão do Gerrit Papedo da documentação em html do djb para o formato man page padrão:

	# cd /usr/ports/sysutils/daemontools
# make
# make install

Então, olhe no script de exemplo de inicialização o port fornece em "/usr/local/share/examples/daemontools/svscan.sh.sample". Edite o arquivo para descomentar todas parametros ulimit recomendados, então copie a versão editada dentro:

	/usr/local/etc/rc.d/svscan.sh
Defina o arquivo com chmod 750. Este script agora controlará a inicialização do processo svscan mestre sobre todos serviços instalados em /var/services. Crie este diretório spool de serviços agora:
	# mkdir /var/service
Para inicializar o svscan sem reiniciar, vá em frente e de o comando:
	# /usr/local/etc/rc.d/svscan.sh start
Agora você pode voltar ao artigo e instalar o djbdns, e whenever o diretórios de serviço criados pelo "dnscache-conf" e/ou "tinydns-conf" são linkados dentro de /var/service, estes serviços inicializarão automaticamente em poucos segundos.

Você deve saber que o instalar o port do FreeBSD do daemontools faz algumas coisas que são distintamente não "the djb way"; isto é, diferente de que você obteria se você fosse instalar o pacote de acordo com as instruções do Bernstein. Isto é porque o daemontools-0.76 sortof pushes o envelope on the whole djb thing, usando as idéias mais recentes do Bernstein para uma hierarquia de sistema de arquivos que a maioria de nós não pode estar completamente pronta para ainda. Por exemplo, com uma instalação do Bernstein, o pacote é construido e remains no local em um nivel-superior /diretório do pacote, os executáveis são linkados dentro de um nivel-superior /diretório comando, e serviços são linkados dentro de um nível-superior /diretório service.

O port do FreeBSD desfaz o esquema de instalação do djb em favor do "the FreeBSD way", assim documentado na hier(7). Isto é , executáveis são instalados como normal em /usr/local/bin, com /var/service recomendado como spool de serviço.O gerenciamento de pacote é de curso manuseado pelo sistema de pacote do FreeBSD nativo, gravado em /var/db/pkg.

Sidenote #1: djbdns port build options

Note que o port FreeBSD do djbdns também permite customização da construção com poucas opções. Para ve-las, verifique:

	# make pre-fetch
antes de iniciar o make. Isto will print uma lista das opções de construção disponíveis controladas pelo definições do make. Assim do FreeBSD 4.6 por exemplo, para construir com o path do Felix von Leitner que abilita o IPv6, faça o port com:
	# make -DWITH_IPV6 
Ou, para preservar um cache built-up entre carregamento do sistema, tente o patch do dumpcache do Florent Guillame:
	# make -DWITH_DNSCACHE_DUMPCACHE
Estas opções de construção são atualmente incompatíveis, e não serão discutidas further neste artigo. Veja a seção "Recusrsos" abaixo para mais informação na instalação e uso deste patches.

Sidenote #2: Distributing Bernstein

Como mencionado neste artigo, você normalmente instalará o software djb do fonte, melhor que de pacotes pré-compilados enviados com a distribuição CD-ROM do seu OS. Se você concorde com pensamento do Bernstein em todos este ou não, "the djb way" adicionar its own interesting twists para a interpretação do licenceamento open source e distribuição de software.

Para começar, você não encontrará um arquivo de LICENÇA acompanhando o djbdns. A premissa e fundamental para Bernstein é o princípio legal do copyright. Isto é, o autor é a única pessoa entitulada para fazer e distribuir cópias de seu trabalho, ao menos e/ou ainda que renunciou,vendeu, licenceou, ou de outra maneira transferriu estes direitos para outros. (os comentários de Bernstein sugerem que ele acredita que licenças do software são unenforceable.)

Se você obtiver uma cópia de seu software obtendo de seu servidor, Bernstein's asserts que não você que fez a cópia. Rather, Bernstein diria que ele fez a cópia para você, as is his right as author to do so, by way of his instructing his server (through its configuration) para fornecer a você com o download. Uma vez que tenha o fonte do ftp'd, então, você tem legalmente adiquirido uma cópia do software do autor, com sua permissã. E o Bernstein has not relinquished ou transferiu quaisquer de seus próprios copyrights para você no processo.

Agora que você legalmente "possui" uma cópia do software, Bernstein maintains that you have a set of legally sanctioned rights and priveleges regarding what you can do with it. Estes incluem fazer backups, aplicar patches e modificações e compilar e executar os programas, tudo sem necessitar de permissões adicionais do suporte do copyright. (Estes são os direitos e privilégios que Bernstein claims aplicar a qualquer software, comercial ou de outra maneira, assim baseado na 17 USC 117, irrespective de qualquer licença assim-chamada no shrink-wrap.) Among os direitos que você não tem neste esquema é o direito to turn around and copy the software yourself for distribution to others. Embora você está livre para aplicar e distribuir seus próprios patches e modificações however you would like, você não está entitulado para redistribuir o original ou o trabalho modificado, derivações, e/ou binários compilados, a menos que você for concedido específicas permissão para faze-lo.

Se nós pararmos neste ponto, os principios considerando distribuição sob "the djb way" certamente fazem parecem mais restritivas que aquelas concedidas sob as licenças Berkeley ou GNU. Em particular, distribuidores de CD-ROM sentem que eles tem um problema quando eles querem incluir programas do Bernstein com seu produtos.

In actual practice, though, "the djb way" does little to impair most user's abilidade de acessar e livremente enjoy the harvest of Bernstein's labor, em whatever modo one could choose. (Por uma coisa, as nós veremos logo, Bernstein does make it possível para mirrors e distributores para incluirem seus programas.) It is even possível para considerar certos possíveis benefícios neste esquema, pelo modo de controle do autor sobre o fonte consistency and distribution integrity. Estas são certamente not trivial concerns estes dias, particularmente com software assim critically central a segurança do sistema.

E aqui está onde Bernstein now goes further e faz algo extraordinário. Ele oferece uma "garantia de segurança", backed by a $500 reward (unclaimed, as far as I know) para alguem que encontrar um buraco na segurança em seu código! Agora compare este the bold print disclaimers da garantia que você encontra em todas suas licensas Berkeley e GNU.

It would seem, então, que Bernstein está escolhendo distribuir livremente seu trabalho sobre o legal umbrella of copyright como um significado de proteger a integridade e segurança de seus projetos. One could further interpret this strategy as an expression of deep, on-going and personal commitment to the quality of software. It would hardly be fair to object to the arrangement. Even where there are other means for managing projects in ways that are both secure and "open", they are not without their own costs and tradeoffs. For example, considering just the hassle factor of following up on claims that may be the result of unidentified forks and mutations, could Bernstein even bother to make his "security guarantee" without asserting the principle of copyright? And how many project developers of any slant, open source or otherwise, are offering cash rewards (and with their own personal money!) for finding flaws in their work? (Knuth's legendary rewards for TeX being the rare precedent.) Speaking as a happy and grateful user of djbdns, I feel the benefits derived from Bernstein's security guarantee far outweigh any of the restrictions, real or imagined, imposed by his copyright protection.

Eu digo imaginei o porque disto: Bernstein de fato fornece permissão explicita para redistribuição de seu código, em ambas formas de fonte e compilado. Verifique seu website, e você encontrará-lo em preto e branco (folhas de estilo não ainda estão sendo um característica do html no "the djb way".) Neste caso do djbdns, por example, Bernstein concede permanente, permissão irrestrita para todos que distribuam cópias exatas do arquivos de fonte. E binários pré-compilados podem também ser distribuídos sem restrição, com a condição que eles estão exatamente como resultariam da instalação padrão do fonte. (Note também que Bernstein tem completamente lançado alguns de seus outros trabalhos, como "cdb", dentro do domínio público.)

No fim , se você é um usuário ou distribuidor, lawyer ou filósofo, it seria difícil encontrar um practical downside em qualquer deles. Aderentes do "the djb way" will download, patch, e construirão do fonte original em qualquer caso. But it's a wide world, de muitas persuasões e paixão, com muitas escolhas de liberdade. Para mim, "the djb way" é somente um modo de muitos fornecimento para a propagação do fantástico, software livre através da cyber-ecologia, increasing a riqueza e diversidade de nossos sistemas no processo.

Recursos e Informação Adicional

Website do Dan Bernstein, o fonte para o djbdns, daemontools, e informação relacionada: http://cr.yp.to/

Website "Life with djbdns" do Henning Brauer: http://lifewithdjbdns.org/

Website "não-oficial" djbdns do Russell Nelson : http://www.djbdns.org/

FAQ "não-oficial" do Felix von Leitner, e outros recursos como um pacth IPv6: http://www.fefe.de/djbdns/

Patch do "dumpcache" do Florent Guillame: http://mapage.noos.fr/efge/djbdns/

Man pages do Gerrit Pape derivado da documentação HTML do Bernstein: http://smarden.org/pape/djb/


Sobre o Autor

Wayne Marshall ([email protected]) é um programador Unix e consultor tecnico na Guinea, Oeste da Africa. Ele e sua esposa estão aproveitando viajando e vivendo na Africa.

Tradução

Gustavo Fukao ([email protected]) .



Autor mantem todos copyrights neste artigo.
Imagens e layout Copyright © 1998-2003 Dæmon News. Todos Diretos Reservados.
Hosted by www.Geocities.ws

1