                   Procedimentos para Construc,ao de Pacotes

  Equipe de Gerenciamento da Colec,ao de Ports do FreeBSD

   Revisao: 43184

   Copyright (c) 2003-2012 Equipe de Gerenciamento da Colec,ao de Ports do
   FreeBSD

   FreeBSD is a registered trademark of the FreeBSD Foundation.

   Intel, Celeron, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are
   trademarks or registered trademarks of Intel Corporation or its
   subsidiaries in the United States and other countries.

   SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc
   in the United States and other countries. SPARC International, Inc owns
   all of the SPARC trademarks and under licensing agreements allows the
   proper use of these trademarks by its members.

   Many of the designations used by manufacturers and sellers to distinguish
   their products are claimed as trademarks. Where those designations appear
   in this document, and the FreeBSD Project was aware of the trademark
   claim, the designations have been followed by the "(TM)" or the "(R)"
   symbol.

   2013-11-13 por hrs.
   [ Documento HTML em partes / Documento HTML completo ]

     ----------------------------------------------------------------------

   Indice

   1. Introduc,ao

   2. Gerenciamento dos Clientes de Compilac,ao

   3. Configurac,ao do Ambiente de Compilac,ao sob Chroot

   4. Customizando Sua Compilac,ao

   5. Iniciando a Compilac,ao

   6. Anatomia de uma compilac,ao

   7. Manutenc,ao da Compilac,ao

   8. Monitorando a Compilac,ao

   9. Lidando com Erros de Compilac,ao

   10. Compilando Pacotes para uma Versao Especifica

   11. Upload dos Pacotes

   12. Compilac,ao de Patches Experimentais

   13. Como configurar um novo no de compilac,ao de pacotes

   14. Como configurar um novo branch do FreeBSD

   15. Como excluir um branch que deixou de ser suportado pelo FreeBSD

   16. Como regerar pacotes baseados em outra versao menor do FreeBSD

   17. Como configurar uma nova arquitetura

   18. Como configurar um novo no principal (instancia do pointyhat)

   19. Procedimentos para lidar com falhas de disco

1. Introduc,ao

   Com o objetivo de disponibilizar binarios pre-compilados de aplicac,oes de
   terceiros para o FreeBSD, a Colec,ao de Ports e regularmente compilada em
   um dos "Clusters de Compilac,ao de Pacotes". Atualmente o principal
   cluster em uso e o http://pointyhat.FreeBSD.org.

   Este artigo documenta os trabalhos internos do cluster

  Nota:

   Muitos dos detalhes deste artigo serao do interesse apenas dos membros da
   equipe que faz o Gerenciamento da Colec,ao de Ports

  1.1. O codigo base

   A maior parte da magica na compilac,ao de pacotes ocorre sob o diretorio
   /var/portbuild. A menos que seja especificado o contrario, todos os
   caminhos serao relativos `a este diretorio. O ${arch} sera usado para
   determinar uma das arquiteturas de pacotes (amd64, i386(TM), ia64,
   powerpc, e SPARC64(R)), e ${branch} sera usado para determinar o branch
   (ramo de desenvolvimento) de compilac,ao (7, 7-exp, 8, 8-exp, 9, 9-exp,
   10, 10-exp).

  Nota:

   Nao sao mais compilados pacotes para as versoes 4, 5 ou 6, e para a
   arquitetura alpha

   Os scripts que controlam todo o processo estao localizados em
   /var/portbuild/scripts/. Eles sao copias obtidas do repositorio Subversion
   base/projects/portbuild/scripts/.

   Normalmente sao feitas compilac,oes incrementais que usam pacotes
   anteriores como dependencias; isso toma menos tempo, e coloca menos carga
   nos sites espelho. Normalmente sao feitas compilac,oes completas apenas
   quando:

     * logo depois de uma nova versao, para o ramo -STABLE

     * periodicamente, para testar mudanc,as realizadas no -CURRENT

     * para compilac,oes experimentais

  1.2. Observac,oes sobre o codigo base

   Ate meados de 2010, os scripts apontavam especificamente para pointyhat
   como o no principal (dispatch). Durante o verao de 2010, mudanc,as
   significativas foram feitas a fim de aceitar outros hosts como nos
   principais. Entre estas mudanc,as estao:

     * remoc,ao da string pointyhat embutida no codigo

     * fatorac,ao de todas as constantes de configurac,ao (que antes estavam
       espalhadas por todo o codigo) em arquivos de configurac,ao (veja
       abaixo)

     * adicionar o hostname aos diretorios especificados pelo buildid (isto
       vai permitir que os diretorios sejam inequivocos quando copiados entre
       maquinas.)

     * tornar os scripts mais robustos em termos de criac,ao de diretorios e
       links simbolicos

     * se necessario, alterar a forma de execuc,ao dos scripts para tornar os
       itens acima mais faceis.

   Este documento foi escrito originalmente antes destas mudanc,as serem
   feitas. Nas partes em que algo foi modificado, como nas invocac,oes de
   scripts, elas estao denotadas como novo codigo base: em oposic,ao `a
   antigo codigo base:.

  Nota:

   Como em dezembro de 2010, o pointyhat ainda esta rodando sobre o antigo
   codigo base, ate que o novo codigo base seja considerado estavel.

  Nota:

   Tambem durante esse processo, o codigo base foi migrado para o repositorio
   Subversion. Para referencia, a versao anterior ainda pode ser encontrada
   no CVS.

2. Gerenciamento dos Clientes de Compilac,ao

   Os clientes i386(TM) localizados conjuntamente com o pointyhat, efetuam o
   boot via rede a partir dele (nos conectados); todos os outros clientes
   (nos desconectados) ou sao auto-hospedados ou efetuam boot via rede a
   partir de outro host pxe. Em todos os casos eles se auto configuram
   durante o boot preparando-se para compilar pacotes.

   O cluster principal copia, atraves do rsync, os dados necessarios (a
   arvore de ports e dos fontes, bindist tarballs, scripts, etc.) para os nos
   desconectados durante a fase de configurac,ao dos nos. Em seguida, o
   diretorio portbuild desconectado e montado como nullfs para compilac,oes
   sob chroot.

   O usuario ports-${arch} pode acessar os nos clientes atraves do ssh(1)
   para monitora-los. Use o sudo e verifique o portbuild.hostname.conf para o
   usuario e detalhes do acesso.

   O script scripts/allgohans pode ser usado para executar um comando em
   todos os clientes ${arch}.

   O script scripts/checkmachines e usado para monitorar a carga em todos os
   nos do cluster de compilac,ao, e agendar quais nos compilarao quais ports.
   Este script nao e muito robusto e tem uma tendencia a morrer. E melhor
   iniciar este script no no principal (por exemplo, pointyhat) depois do
   boot usando um loop com while(1).

3. Configurac,ao do Ambiente de Compilac,ao sob Chroot

   A compilac,ao de pacotes e realizada em um ambiente chroot, configurado
   pelo script portbuild usando o arquivo
   ${arch}/${branch}/builds/${buildid}/bindist.tar.

   O seguinte comando faz o build world a partir da arvore de diretorios em
   ${arch}/${branch}/builds/${buildid}/src/ e o instala em ${worlddir}. A
   arvore de diretorios sera atualizada primeiro, a menos que a opc,ao -nocvs
   seja especificada.

 /var/portbuild# scripts/makeworld ${arch} ${branch} ${buildid} [-nocvs]

   O arquivo bindist.tar e criado a partir do world, instalado previamente,
   pelo script mkbindist. Este deve ser executado como root com o seguinte
   comando:

 /var/portbuild# scripts/mkbindist ${arch} ${branch} ${buildid}

   Os tarballs de cada maquina estao localizados em ${arch}/clients.

   O arquivo bindist.tar e extraido para cada cliente durante a
   inicializac,ao dos mesmos, e no inicio de cada passagem do script
   dopackages.

  3.1. Novo Codigo Base

   Para ambos os comandos acima, se o ${buildid} estiver definido como
   latest, ele pode ser omitido.

4. Customizando Sua Compilac,ao

   (O trecho a seguir aplica-se apenas ao novo codigo base.)

   Voce pode customizar sua compilac,ao providenciando versoes locais do
   make.conf e/ou src.conf, localizados em
   ${arch}/${branch}/builds/${buildid}/make.conf.server e
   ${arch}/${branch}/builds/${buildid}/src.conf.server, respectivamente.
   Estes serao usados, em vez dos arquivos padroes que estao no lado do
   servidor.

   Da mesma forma, se voce tambem quiser afetar o make.conf no lado do
   cliente, voce pode usar o
   ${arch}/${branch}/builds/${buildid}/make.conf.client.

  Nota:

   Devido ao fato de cada um dos clientes individuais poder ter seu proprio
   make.conf, o conteudo do
   ${arch}/${branch}/builds/${buildid}/make.conf.client vai ser adicionado ao
   make.conf, e nao substitui-lo, como e feito com o
   ${arch}/${branch}/builds/${buildid}/make.conf.server.

  Nota:

   Nao existe nenhuma funcionalidade semelhante para
   ${arch}/${branch}/builds/${buildid}/src.conf.client (e que efeito teria?).

   Exemplo 1. Exemplo de make.conf.target para testar a nova versao padrao do
   ruby

   (Neste caso, os conteudos sao identicos para ambos, servidor e cliente.)

 RUBY_DEFAULT_VER= 1.9

   Exemplo 2. Exemplo de make.conf.target para compilac,ao do clang

   (Neste caso, os conteudos tambem sao identicos para ambos, servidor e
   cliente.)

 .if !defined(CC) || ${CC} == "cc"
 CC=clang
 .endif
 .if !defined(CXX) || ${CXX} == "c++"
 CXX=clang++
 .endif
 .if !defined(CPP) || ${CPP} == "cpp"
 CPP=clang-cpp
 .endif
 # Don't die on warnings
 NO_WERROR=
 WERROR=

   Exemplo 3. Exemplo de make.conf.server para pkgng

 WITH_PKGNG=yes
 PKG_BIN=/usr/local/sbin/pkg

   Exemplo 4. Exemplo de make.conf.client para pkgng

 WITH_PKGNG=yes

   Exemplo 5. Exemplo de src.conf.server para testar uma versao nova do
   codigo base do sort

 WITH_BSD_SORT=yes

5. Iniciando a Compilac,ao

   Varias compilac,oes separadas para cada arquitetura - a combinac,ao de
   branchs e suportada. Todos os dados privados para uma compilac,ao (arvore
   de ports, arvore do src, pacotes, distfiles, arquivos de log, bindist,
   Makefile, etc) estao localizados sob ${arch}/${branch}/builds/${buildid}.
   Alternativamente, a ultima compilac,ao pode ser referenciada sob o buildid
   latest, e a anterior a esta e chamada previous.

   Novas compilac,oes sao clonadas a partir da latest, o que e rapido, uma
   vez que ele usa ZFS.

  5.1. Os Scripts dopackages

   Os scripts scripts/dopackages sao usados para executar as compilac,oes.

    5.1.1. Codigo base antigo

   Para o codigo base antigo, os mais uteis sao:

     * dopackages.7 - Executa a compilac,ao para a serie 7.X

     * dopackages.7-exp - Executa a compilac,ao para a serie 7.X com patches
       experimentais (branch 7-exp)

     * dopackages.8 - Executa a compilac,ao para a serie 8.X.

     * dopackages.8-exp - Executa a compilac,ao para a serie 8.X com patches
       experimentais (branch 8-exp)

     * dopackages.9 - Executa a compilac,ao para a serie 9.X.

     * dopackages.9-exp - Executa a compilac,ao para a serie 9.X com patches
       experimentais (branch 9-exp)

     * dopackages.10 - Executa a compilac,ao para a serie 10.X.

     * dopackages.10-exp - Executa a compilac,ao para a serie 10.X com
       patches experimentais (branch 10-exp)

   Esses sao wrappers para o dopackages e todos sao links simbolicos para
   dopackages.wrapper. Wrappers de scripts para um novo branch podem ser
   criados com links simbolicos dopackages.${branch} para dopackages.wrapper.
   Esses scripts tem uma serie de argumentos. Por exemplo:

 dopackages.7 ${arch} ${buildid} [-options]

    5.1.2. Novo codigo base

   Voce pode usar o dopackages.wrapper diretamente, ao inves dos links
   simbolicos. Por exemplo:

 dopackages.wrapper ${arch} ${branch} ${buildid} [-options]

    5.1.3. Para ambos os codigos base

   Frequentemente voce usara latest como valor para o buildid.

   [-options] pode ser nulo, uma ou mais, das opc,oes seguintes:

     * -keep - Nao remove esta compilac,ao no futuro, quando normalmente
       seria removido como parte do ciclo latest - previous. Nao se esquec,a
       de efetuar a limpeza manualmente quando ele nao for mais necessario.

     * -nofinish - Nao executa o pos-processamento apos finalizar a
       compilac,ao. Isto e util se voce espera que a compilac,ao precise ser
       reiniciada depois de concluida. Se voce usar esta opc,ao, nao se
       esquec,a de limpar os clientes quando voce nao precisar mais da
       compilac,ao.

     * -finish - Executa apenas o pos-processamento.

     * -nocleanup - Por padrao, quando o estagio -finish da compilac,ao e
       completado, os dados da compilac,ao serao removidos dos clientes. Esta
       opc,ao vai evitar a remoc,ao dos dados.

     * -restart - Reinicia uma compilac,ao interrompida (ou nao finalizada) a
       partir do comec,o. Os Ports que falharam na compilac,ao anterior serao
       recompilados.

     * -continue - Reinicia uma compilac,ao interrompida (ou nao finalizada).
       Os Ports que falharam na compilac,ao anterior nao serao recompilados.

     * -incremental - Compara os campos importantes do novo INDEX com a
       versao anterior, remove pacotes e arquivos de log dos ports antigos
       que foram alterados, e recompila o resto. Isso reduz o tempo de
       compilac,ao substancialmente, pois os ports inalterados nao serao
       recompilados todas as vezes.

     * -cdrom - O empacotamento desta compilac,ao sera usado em um CD-ROM,
       entao os pacotes marcados como NO_CDROM e os disfiles deverao ser
       removidos no pos-processamento.

     * -nobuild - executa todas as etapas do pre-processamento, mas nao a
       compilac,ao dos pacotes.

     * -noindex - Nao reconstroi o INDEX durante o pre-processamento.

     * -noduds - Nao reconstroi o arquivo duds (ports que nunca sao
       compilados, como por exemplo, aqueles marcados com IGNORE, NO_PACKAGE,
       etc.) durante o pre-processamento.

     * -nochecksubdirs - Nao verifica o SUBDIRS para os ports que nao estao
       ligados `a compilac,ao. (Apenas para o novo codigo base).

     * -trybroken - Tenta compilar ports marcados como BROKEN (desativado por
       padrao, pois os clusters amd64/i386(TM) agora sao suficientemente
       rapidos e quando fazem compilac,oes incrementais eles gastam muito
       mais tempo do que o necessario para compilar tudo. Por outro lado, os
       outros clusters sao bastante lentos, e seria um desperdicio de tempo
       tentar compilar ports marcados como BROKEN).

  Nota:

       Com -trybroken, provavelmente voce tambem vai querer usar
       -fetch-original (e, no novo codigo base, -unlimited-errors).

     * -nosrc - Nao atualiza a arvore do src a partir do snapshot do ZFS,
       mantendo a arvore da compilac,ao anterior.

     * -srccvs - Nao atualiza a arvore do src a partir do snapshot do ZFS, em
       vez disso ela e atualizada com o cvs update.

     * -noports - Nao atualiza a arvore de ports a partir do snapshot do ZFS,
       mantendo a arvore da compilac,ao anterior.

     * -portscvs - Nao atualiza a arvore de ports a partir do snapshot do
       ZFS, em vez disso ela e atualizada com o cvs update.

     * -norestr - Nao tenta compilar ports marcados como RESTRICTED.

     * -noplistcheck - Nao considera como erro ports deixarem arquivos para
       tras ao serem removidos.

     * -nodistfiles - Nao coleta os distfiles que passarem no make checksum
       para depois fazer o upload para o ftp-master.

     * -fetch-original - Baixa o distfile a partir do MASTER_SITES original,
       em vez do ftp-master.

     * -unlimited-errors (apenas no novo codigo base) - anula a verificac,ao
       de limites do qmanager para compilac,oes descontroladas. Voce pode
       querer isso principalmente quando usar -restart em uma compilac,ao que
       provavelmente vai falhar, ou talvez quando executar -trybroken. A A
       limitac,ao e realizada por padrao.

   A menos que voce especifique -restart, -continue, ou -finish, os links
   simbolicos para as compilac,oes existentes serao rotacionados. Isto e, o
   link simbolico para previous sera removido; a compilac,ao mais recente
   tera seu link modificado para previous/; e a nova compilac,ao sera criada
   e referenciada com um link em latest/.

   Se a ultima compilac,ao finalizou de forma limpa, voce nao precisa remover
   nada. Se ela foi interrompida, ou voce usou a opc,ao -nocleanup, voce
   precisa limpar os clientes executando:

   build cleanup ${arch} ${branch} ${buildid} -full

   Os diretorios errors/, logs/, packages/, e assim por diante, sao limpos
   pelos scripts. Se voce esta com pouco espac,o, tambem pode limpar o
   ports/distfiles/. Nao altere o diretorio latest/; ele e um link simbolico
   para o servidor web.

  Nota:

   O dosetupnodes supostamente e executado pelo script dopackages no caso de
   -restart, mas pode ser uma boa ideia executa-lo manualmente e depois
   verificar se todos os clientes tem a carga de trabalho esperada. Algumas
   vezes dosetupnode nao pode limpar uma compilac,ao e voce precisara fazer
   isso manualmente. (Isto e um defeito.)

   Verifique se a compilac,ao de pacotes para a arquitetura ${arch} esta
   executando como usuario ports-${arch} ou ele apresentara um grande numero
   de erros.

  Nota:

   Atualmente, a propria compilac,ao de pacotes ocorre em duas fases
   identicas. A razao para isso e que, algumas vezes, problemas temporarios
   (por exemplo, falhas do NFS, sites FTP inalcanc,aveis, etc.) podem quebrar
   a compilac,ao. Realizar o processo em duas fases e uma soluc,ao
   alternativa para esse tipo de problema.

   Seja cuidadoso com ports/Makefile para nao especificar qualquer diretorio
   vazio. Isso e especialmente importante se voce esta realizando uma
   compilac,ao com patches experimentais (-exp). Se o processo de compilac,ao
   encontrar um diretorio vazio, ambas as fases de compilac,ao irao parar
   rapidamente, e um erro similar ao seguinte sera adicionado para
   ${arch}/${branch}/make.[0|1]:

 don't know how to make dns-all(continuing)

   Para corrigir este problema, simplesmente comente ou remova as entradas
   SUBDIR que apontam para subdiretorios vazios. Depois de feito isso, voce
   pode reiniciar a compilac,ao executando o comando dopackages adequado com
   a opc,ao -restart.

  Nota:

   Este problema tambem ocorre se voce criar uma nova categoria com um
   Makefile sem entradas SUBDIRs nele. Isso e, provavelmente, um defeito.

   Exemplo 6. Atualize a arvore i386-7 e fac,a uma compilac,ao completa

   dopackages.7 i386 -nosrc -norestr -nofinish

   dopackages.wrapper i386 7 -nosrc -norestr -nofinish

   Exemplo 7. Reinicie uma compilac,ao para amd64-8 interrompida sem
   atualizar

   dopackages.8 amd64 -nosrc -noports -norestr -continue -noindex -noduds
   -nofinish

   dopackages.wrapper amd64 8 -nosrc -noports -norestr -continue -noindex
   -noduds -nofinish

   Exemplo 8. Realize o pos-processamento de uma arvore sparc64-7 concluida

   dopackages.7 sparc64 -finish

   dopackages.wrapper sparc64 7 -finish

   Dica: geralmente e melhor executar o comando dopackages dentro do
   screen(1).

  5.2. O comando build

   Voce pode precisar manipular os dados da compilac,ao antes de inicia-la,
   especialmente para compilac,oes experimentais. Isto e feito com o comando
   build. Aqui estao algumas opc,oes uteis para criac,ao:

     * build create arch branch [newid] - Cria um newid (ou um datestamp, se
       nao for especificado). So e necessario quando da criac,ao de um novo
       branch ou uma nova arquitetura. (TODO: documentar se newid deve ser
       especificado como latest no novo codigo base.)

     * build clone arch branch oldid [newid] - Cria um clone do oldid para o
       newid (ou um datestamp, se nao for especificado).

     * build srcupdate arch branch buildid - Substitui a arvore src com um
       novo snapshot do ZFS. Nao se esquec,a de usar a opc,ao -nosrc quando
       executar o dopackages mais tarde!

     * build portsupdate arch branch buildid - Substitui a arvore de ports
       com um novo snapshot do ZFS. Nao se esquec,a de usar a opc,ao -noports
       quando executar dopackages mais tarde!

  5.3. Compilando um unico pacote

   Algumas vezes e necessario recompilar um unico pacote a partir do conjunto
   de pacotes. Isso pode ser feito executando o seguinte comando:

   path/qmanager/packagebuild amd64 7-exp 20080904212103 aclock-0.2.3_2.tbz

6. Anatomia de uma compilac,ao

   Uma compilac,ao completa, sem qualquer opc,ao -no que desabilite as
   opc,oes padroes, executa as seguintes operac,oes na ordem especificada:

    1. Atualiza a arvore de ports atual a partir de um snapshot do ZFS [*]

    2. Atualiza o branch usado na arvore src a partir de um snapshot do ZFS
       [*]

    3. Verifica se ports nao tem uma entrada SUBDIR no Makefile de suas
       respectivas categorias [*]

    4. Cria o arquivo duds, que e uma lista de ports que nao precisam ser
       compilados [*] [+]

    5. Cria um arquivo INDEX atualizado [*] [+]

    6. Define os nos que serao usados na compilac,ao [*] [+]

    7. Compila uma lista de ports restritos [*] [+]

    8. Compila os pacotes (fase 1) [++]

    9. Executa outra configurac,ao do no [+]

   10. Compila os pacotes (fase 2) [++]

   [*] O status destes passos pode ser encontrado em
   ${arch}/${branch}/build.log, bem como no stderr do tty onde o comando
   dopackages esta rodando.

   [+] Se qualquer destes passos falhar, a compilac,ao sera encerrada.

   [++] O status destes passos pode ser encontrado em ${arch}/${branch}/make
   (antigo codigo base) ou ${arch}/${branch}/journal (novo codigo base).
   Ports individuais irao escrever seus logs de compilac,ao em
   ${arch}/${branch}/logs e os seus logs de erros em
   ${arch}/${branch}/errors.

   Anteriormente, a arvore docs tambem era verificada, no entanto, isso se
   mostrou desnecessario.

7. Manutenc,ao da Compilac,ao

   Existem varios casos onde voce precisara limpar manualmente uma
   compilac,ao:

    1. Voce a interrompeu manualmente.

    2. O pointyhat foi reiniciado enquanto uma compilac,ao estava executando.

    3. O qmanager falhou e reiniciado

  7.1. Interrompendo uma Compilac,ao

   O processo para interromper de forma manual uma compilac,ao e um tanto
   quanto confuso. Primeiro voce precisa identificar o tty em que ela esta
   sendo executada rodando (ou lembrando-se da saida do tty(1) quando voce
   iniciou a compilac,ao, ou usando ps x para identifica-lo). Voce precisa
   certificar-se de que nao existe mais nada importante rodando neste tty,
   voce pode verificar isto executando o comando ps, por exemplo, ps -t p1
   lista os processos em execuc,ao no tty 1. Se nao existir mais nada
   importante, voce pode encerrar o terminal facilmente com pkill -t pts/1;
   ou pode utilizar o kill -HUP, por exemplo, ps -t pts/1 -o pid= | xargs
   kill -HUP. Voce deve Substitur o p1 pelo tty utilizado na compilac,ao.

   A compilac,ao de pacote enviada pelo make para as maquinas clientes ira se
   auto limpar apos alguns minutos (verifique com ps x ate que todos
   finalizem).

   Se voce nao encerrar o make(1), ele ira iniciar novas tarefas de
   compilac,ao. Se voce nao encerrar o dopackages ele ira reiniciar toda a
   compilac,ao. Se voce nao encerrar os processos pdispatch, eles irao
   continuar (ou reaparecer) ate concluir a compilac,ao do pacote.

  7.2. Limpando uma Compilac,ao

   Para liberar recursos, voce precisa limpar as maquinas clientes executando
   o comando build cleanup. Por exemplo:

 % /var/portbuild/scripts/build cleanup i386 8-exp 20080714120411 -full

   Se voce esquecer de fazer isso, entao os chroots da compilac,ao antiga nao
   serao limpos nas proximas 24 horas, e nenhum novo trabalho sera iniciado
   no seu lugar enquanto o pointyhat achar que esta maquina ainda esta
   ocupada.

   Para verificar, utilize o comando cat ~/loads/* para mostrar o status das
   maquinas clientes; a primeira coluna e o numero de trabalhos que ela pensa
   estar executando, e isso pode estar bem proximo da carga media. O loads e
   atualizado a cada 2 minutos. Se voce executar um ps x | grep pdispatch e
   ele listar menos trabalhos do que os que o loads pensa estarem em uso,
   voce esta em apuros.

   Voce pode ter problemas com instancias do comando umount ficando
   congeladas. Se isto ocorrer, voce tera que usar o script allgohans para
   executar um comando ssh(1) em todos os clientes deste ambiente de
   compilac,ao. Por exemplo:

 ssh -l root gohan24 df

   Vai lhe dar um df, e

 allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports"
 allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/src"

   Supostamente ira resolver o problema dos mounts que nao foram
   desconectados pelo umount. Voce tera que continuar executando-os pois
   podem existir diversas montagens.

  Nota:

   Ignore o seguinte:

 umount: pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports: statfs: No such file or directory
 umount: pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports: unknown file system
 umount: Cleanup of /x/tmp/8-exp/chroot/53837/compat/linux/proc failed!
 /x/tmp/8-exp/chroot/53837/compat/linux/proc: not a file system root directory

   Os dois primeiros significam que o cliente nao tinha o sistema de arquivos
   montado; os dois ultimos sao um defeito.

   Voce tambem podera ver mensagens sobre o procfs.

   Apos concluir tudo que foi exposto acima, remova o arquivo ${arch}/lock
   antes de tentar reiniciar a compilac,ao. Se voce nao o fizer, o dopackages
   simplesmente sera encerrado.

   Se voce atualizou a arvore de ports antes de reiniciar, voce pode precisar
   reconstruir o duds, o INDEX, ou ambos os arquivos.

  7.3. Manutenc,ao de compilac,oes com o comando build

   Aqui esta o resto das opc,oes para o comando build:

     * build destroy arch branch - Destroi o id da compilac,ao.

     * build list arch branch - Mostra o conjunto atual de ids de
       compilac,oes.

     * build upload arch branch - ainda nao implementado.

8. Monitorando a Compilac,ao

   Voce pode usar o comando qclient para monitorar o status dos nos de
   compilac,ao, e para listar as tarefas de compilac,ao agendadas para
   execuc,ao:

   python path/qmanager/qclient jobs

   python path/qmanager/qclient status

   O comando scripts/stats ${branch} mostra o numero de pacotes cuja
   compilac,ao ja finalizou.

   A execuc,ao de um cat /var/portbuild/*/loads/* ira mostrar o load nos
   clientes e o numero de compilac,oes simultaneas em andamento. Os arquivos
   que foram atualizados recentemente correspondem aos clientes que estao
   online; os demais arquivos sao dos clientes que estao offline.

  Nota:

   O comando pdispatch faz o envio de trabalhos para o cliente, e executa
   tarefas de pos-processamento a partir do retorno recebido do client. O
   ptimeout.host monitora permanentemente o processo de compilac,ao e a
   encerra apos a ocorrencia de timeouts. Desta forma, se voce tiver 50
   processos pdispatch, mas apenas 4 processos ssh(1), significa que 46
   processos pdispatches estao ociosos, esperando que um no fique livre.

   Executar tail -f ${arch}/${branch}/build.log ira mostrar o progresso geral
   da compilac,ao.

   Se a compilac,ao do port falhar, e o motivo nao ficar imediatamente obvio
   a partir da analise do log, voce pode preservar o WRKDIR para uma analise
   mais aprofundada. Para fazer isso, crie um arquivo vazio chamado .keep no
   diretorio do port, isso vai arquivar, comprimir, e copiar o WRKDIR para
   ${arch}/${branch}/wrkdirs.

   Se voce verificar que o sistema esta compilando o mesmo pacote de forma
   ciclica, repetindo o processo indefinidamente, voce pode ser capaz de
   corrigir o problema reconstruindo manualmente o pacote ofensor.

   Se todas as compilac,oes iniciam reclamando de que nao pode carregar os
   pacotes dos quais ela depende, verifique se o httpd ainda esta rodando, e
   o i reinicie se nao estiver.

   Mantenha o olho na saida do df(1). Se o sistema de arquivos do
   /var/portbuild ficar cheio, coisas ruins acontecem.

   O status de todas as compilac,oes e gerado duas vezes por hora e postado
   em http://pointyhat.FreeBSD.org/errorlogs/packagestats.html. Para cada
   buildenv e apresentado o seguinte:

     * cvs date e o conteudo do cvsdone. E por isso que nos recomendamos que
       voce atualize o cvsdone para executar compilac,oes experimentais, -exp
       (veja abaixo).

     * data do ultimo log (latest log)

     * numero de linhas no INDEX

     * o numero atual de logs de compilac,oes (build logs)

     * o numero de pacotes concluidos (packages)

     * o numero de erros (errors)

     * o numero de ports ignorados (duds) (listados como skipped)

     * A coluna missing mostra a diferenc,a entre o INDEX e as outras
       colunas. Se voce reiniciou uma compilac,ao apos um cvs update,
       provavelmente havera duplicatas nos pacotes e colunas de erros, e esta
       coluna sera inutil. (O script e ingenuo).

     * Os valores das colunas running e completed sao palpites baseados em um
       grep(1) do build.log.

9. Lidando com Erros de Compilac,ao

   A maneira mais facil de rastrear falhas na compilac,ao e receber os logs
   enviados por e-mail e organiza-los em uma pasta, assim voce pode manter
   uma lista com as falhas atuais e detectar facilmente as novas. Para fazer
   isto, adicione um enderec,o de e-mail ao ${branch}/portbuild.conf. Voce
   pode encaminhar facilmente os novos erros para os mantenedores.

   Quando um port passa a nao compilar corretamente durante varios ciclos de
   compilac,ao seguidos, e hora de marca-lo como quebrado (BROKEN).
   Recomenda-se notificar os mantenedores durante duas semanas, antes de
   faze-lo.

  Nota:

   Para evitar erros de compilac,ao dos ports cujo codigo fonte precisa ser
   baixado manualmente, coloque os distfiles em ~ftp/pub/FreeBSD/distfiles.
   Restric,oes de acesso foram implementadas para garantir que apenas os
   clientes de compilac,ao tenham acesso a este diretorio.

10. Compilando Pacotes para uma Versao Especifica

   Ao compilar pacotes para uma versao especifica do FreeBSD, pode ser
   necessario atualizar manualmente as arvores do ports e do src para a tag
   da versao desejada e usar as opc,oes -nocvs e -noportscvs.

   Para compilar conjuntos de pacotes que serao usados em um CD-ROM, use a
   opc,ao -cdrom para o comando dopackages.

   Se nao houver espac,o em disco disponivel no cluster, use -nodistfiles
   para que os distfiles nao sejam baixados.

   Apos completar a compilac,ao inicial, reinicie a compilac,ao com -restart
   -fetch-original para baixar os distfiles atualizados. Entao, uma vez que a
   compilac,ao tiver sido pos-processada, fac,a um inventario da lista de
   arquivos baixados:

 % cd ${arch}/${branch}
 % find distfiles > distfiles-${release}

   Este arquivo de inventario normalmente fica localizado em i386/${branch}
   no no principal do cluster.

   Isto e util para ajudar na limpeza periodica dos distfiles do ftp-master.
   Quando o espac,o se torna escasso, os distfiles das versoes recentes podem
   ser mantidos, enquanto outros podem ser jogados fora.

   Uma vez que o upload dos distfiles tenha sido feito (veja abaixo), o
   conjunto de pacotes da versao final deve ser criado. Para se assegurar,
   execute manualmente o script ${arch}/${branch}/cdrom.sh para certificar-se
   de que todos os pacotes com distribuic,ao restrita via CD-ROM e todos os
   distfiles foram removidos. Entao, copie o diretorio
   ${arch}/${branch}/packages para ${arch}/${branch}/packages-${release}. Uma
   vez que os pacotes tenham sido movidos com seguranc,a, contate o Time de
   engenharia de Lanc,amento <re@FreeBSD.org> e informe-os da localizac,ao
   dos pacotes do release.

   Lembre-se de coordenar com o Time de engenharia de Lanc,amento
   <re@FreeBSD.org> sobre o timing e o status das compilac,oes do release.

11. Upload dos Pacotes

   Uma vez que a compilac,ao tenha terminado, os pacotes e/ou distfiles podem
   ser transferidos para o ftp-master para serem propagados para a rede de
   espelhos FTP. Se a compilac,ao foi executada com a opc,ao -nofinish, entao
   certifique-se de executar em seguida o comando dopackages -finish para
   realizar o pos-processamento dos pacotes (remover pacotes marcados como
   RESTRICTED ou como NO_CDROM onde for apropriado, remover pacotes nao
   listados no INDEX, remover do INDEX as referencias para pacotes nao
   compilados, e gerar um sumario CHECKSUM.MD5); e dos distfiles (move-los do
   diretorio temporario distfiles/.pbtmp para o diretorio distfiles/ e
   remover os distfiles marcados como RESTRICTED e NO_CDROM).

   E recomendado que se execute manualmente os scripts restricted.sh e/ou
   cdrom.sh apos a finalizac,ao do dopackages, apenas por seguranc,a. Execute
   o script restricted.sh antes de fazer o upload para o ftp-master, em
   seguida, execute cdrom.sh antes de preparar o conjunto final de pacotes
   para um release.

   Os subdiretorios de pacotes sao nomeados de acordo com a versao e branch
   ao qual se destinam. Por exemplo:

     * packages-7.2-release

     * packages-7-stable

     * packages-8-stable

     * packages-9-stable

     * packages-10-current

  Nota:

   Alguns destes diretorios no ftp-master sao na verdade links simbolicos.
   Por exemplo:

     * packages-stable

     * packages-current

   Certifique-se de que voce esta movendo os novos pacotes para um diretorio
   de destino real, e nao para um dos links simbolicos que apontam para ele.

   Se voce esta preparando um conjunto de pacotes completamente novo (por
   exemplo, para um novo release), copie os pacotes para a area de teste do
   ftp-master executando algo como mostrado abaixo:

 # cd /var/portbuild/${arch}/${branch}
 # tar cfv - packages/ | ssh portmgr@ftp-master tar xfC - w/ports/${arch}/tmp/${subdir}

   Em seguida, entre no ftp-master e verifique se o conjunto de pacotes foi
   transferido com sucesso, remova o conjunto de pacotes que o novo conjunto
   vai substituir (em ~/w/ports/${arch}), e mova o novo conjunto para o
   local. (w/ e apenas um atalho.)

   Para compilac,oes incrementais, o upload deve ser feito usando o rsync
   para nao colocar muita pressao nos espelhos.

   SEMPRE use o rsync primeiro com a opc,ao -n e verifique a saida do comando
   para assegurar-se que nao existem problemas. Se parece estar tudo bem,
   execute novamente o rsync sem a opc,ao -n.

   Exemplo de sintaxe do comando rsync para o upload incremental de pacotes:

 # rsync -n -r -v -l -t -p --delete packages/ portmgr@ftp-master:w/ports/${arch}/${subdir}/ | tee log

   Os distfiles devem ser transferidos utilizando-se o script cpdistfiles:

 # /var/portbuild/scripts/cpdistfiles ${arch} ${branch} ${buildid} [-yesreally] | tee log2

   A execuc,ao manual deste processo e um procedimento obsoleto.

12. Compilac,ao de Patches Experimentais

   Compilac,oes de patches experimentais sao executadas de tempos em tempos
   para novas func,oes ou correc,oes de defeitos na infraestrutura do ports
   (isto e, bsd.port.mk), ou para testar atualizac,oes em grande escala. A
   qualquer momento podem haver varios patches de branchs experimentais
   simultaneos, como o 8-exp na arquitetura amd64.

   Geralmente, a compilac,ao de patches experimentais e executada da mesma
   forma que qualquer outra compilac,ao, exceto que voce deve primeiro
   atualizar a arvore de ports para a ultima versao e, em seguida, aplicar os
   seus patches. Para fazer o primeiro, voce pode usar o seguinte:

 % cvs -R update -dP > update.out
 % date > cvsdone

   Essa e a simulac,ao mais proxima do que o script dopackages faz. (Embora o
   cvsdone seja meramente informativo, ele pode ser util.)

   Voce precisara editar o update.out para procurar por linhas que comecem
   com ^M, ^C, ou ^? para que possa corrigi-las.

   E sempre uma boa ideia salvar copias do original de todos os arquivos
   modificados, bem como uma lista do que voce esta modificando. Voce pode
   consultar a lista ao fazer o commit final, para se certificar de que voce
   esta realizando o commit exatamente daquilo que testou.

   Pelo fato da maquina ser compartilhada, alguem pode excluir suas
   alterac,oes por engano, entao mantenha copias destas, por exemplo, no seu
   diretorio home freefall freefall. Nao use o tmp/; pois a pointyhat executa
   ele mesmo alguma versao do -CURRENT, voce pode esperar por
   reinicializac,oes (no minimo para atualizac,oes).

   Para que voce tenha uma compilac,ao de controle com a qual possa comparar
   eventuais falhas, voce deve primeiro executar a compilac,ao de pacote no
   branch em que os patches experimentais foram baseados para a arquitetura
   i386(TM) (atualmente esta e o 8). Quando estiver preparando a compilac,ao
   dos patches experimentais, fac,a o checkout da arvore do ports e do src
   com a mesma data da que foi usada para a compilac,ao de controle. Isso vai
   garantir uma comparac,ao valida entre as compilac,oes depois.

   Uma vez terminada a compilac,ao, compare as falhas da compilac,ao de
   controle com as da compilac,ao dos patches experimentais. Para facilitar,
   use os seguintes comandos (assumindo o branch 8 como branch de controle, e
   o 8-exp como branch experimental):

 % cd /var/portbuild/i386/8-exp/errors
 % find . -name \*.log\* | sort > /tmp/8-exp-errs
 % cd /var/portbuild/i386/8/errors
 % find . -name \*.log\* | sort > /tmp/8-errs

  Nota:

   Se ja faz muito tempo desde que a ultima compilac,ao foi finalizada, os
   logs podem ter sido compactados automaticamente com bzip2. Nesse caso voce
   deve usar sort | sed 's,\.bz2,,g' em seu lugar.

 % comm -3 /tmp/8-errs /tmp/8-exp-errs | less

   Este ultimo comando vai gerar um relatorio com duas colunas. A primeira
   coluna contem os ports que falharam na compilac,ao de controle, mas nao na
   compilac,ao com patches experimentais; a segunda e o inverso As razoes
   para o port estar na primeira coluna incluem:

     * O port foi corrigido desde que a compilac,ao de controle foi
       executada, ou foi atualizado para uma nova versao que tambem esta
       quebrada (assim a nova versao tambem deve aparecer na segunda coluna)

     * O port foi corrigido pelos patches experimentais na compilac,ao
       experimental

     * O port nao foi compilado na compilac,ao com patches experimentais
       devido a falha de uma dependencia

   Razoes para o port aparecer na segunda coluna incluem:

     * O port foi quebrado pelos patches experimentais [1]

     * O port foi atualizado desde a compilac,ao de controle e deixou de
       compilar [2]

     * O port foi quebrado devido a um erro temporario (por exemplo, site FTP
       fora do ar, erro do pacote cliente, etc.)

   Ambas as colunas devem ser investigadas e as razoes para os erros
   entendidas antes do commit do conjunto de patches experimentais. Para
   diferenciar entre o [1] e o [2] acima, voce pode recompilar os pacotes
   afetados sob o branch de controle:

 % cd /var/portbuild/i386/8/ports

  Nota:

   Certifique-se de atualizar esta arvore com o cvs update para a mesma data
   da arvore dos patches experimentais.

   O seguinte comando vai configurar o branch de controle para a compilac,ao
   parcial (antigo codigo base):

 % /var/portbuild/scripts/dopackages.8 -noportscvs -nobuild -nocvs -nofinish

   As compilac,oes devem ser executadas a partir do diretorio packages/All.
   Este diretorio deve estar vazio inicialmente, exceto pelo link simbolico
   do Makefile. Se este link simbolico nao existir, ele deve ser criado:

 % cd /var/portbuild/i386/8/packages/All
 % ln -sf ../../Makefile .
 % make -k -j<#> <list of packages to build>

  Nota:

   O <#> e o numero de compilac,oes paralelas para tentar. Normalmente isso e
   a soma dos pesos listados em /var/portbuild/i386/mlist, a menos que voce
   tenha uma razao para executar uma compilac,ao mais pesada ou leve.

   A lista de pacotes para compilar deve ser uma lista do nome do pacote
   (incluindo as versoes) como aparece no INDEX. O PKGSUFFIX (isto e, .tgz ou
   .tbz) e opcional.

   Isto vai compilar apenas os pacotes listados, bem como todas as suas
   dependencias.

   Voce pode verificar o progresso da compilac,ao parcial da mesma forma que
   voce faria com uma compilac,ao normal.

   Uma vez que todos os erros tenham sido resolvidos, voce pode efetuar o
   commit do conjunto de pacotes. Apos efetuar o commit, e de costume enviar
   um e-mail para ports@FreeBSD.org e com copia para
   ports-developers@FreeBSD.org, informando as pessoas sobre as mudanc,as. Um
   resumo de todas as mudanc,as tambem deve registrado no arquivo
   /usr/ports/CHANGES.

13. Como configurar um novo no de compilac,ao de pacotes

   Antes de seguir estes passos, por favor, converse com o portmgr.

  Nota:

   Devido `a algumas doac,oes generosas, o portmgr nao esta mais procurando
   por emprestimos de sistemas i386(TM) ou amd64. No entanto, nos ainda
   estamos interessados no emprestimo de sistemas tier-2.

  13.1. Requisitos do no

   O portmgr ainda esta trabalhando para definir quais sao caracteristicas
   que um no necessita possuir para ser util.

     * Capacidade de CPU: qualquer coisa abaixo de 500MHz geralmente nao e
       util para a compilac,ao de pacotes.

  Nota:

       Nos somos capazes de ajustar o numero de tarefas enviadas para cada
       maquina, e nos geralmente ajustamos o numero para fazer uso de 100% da
       CPU.

     * RAM: O minimo utilizavel e 2G; o ideal e ter 8G ou mais. Normalmente
       configuramos uma tarefa para cada 512M de RAM.

     * Disco: E necessario um minimo de 20G para o sistema de arquivos e de
       32G para a area de swap. O desempenho sera melhor se multiplos discos
       forem utilizados, e configurados como geom stripes. Os dados de
       desempenho tambem estao em fase de definic,ao.

  Nota:

       A compilac,ao de pacotes ira estressar as unidades de disco ate o seu
       limite (ou alem dele). Esteja consciente do que voce esta se
       voluntariando para fazer!

     * largura de banda de rede: Ainda nao existe um estudo preciso, no
       entanto uma maquina configurada para 8 tarefas simultaneas se mostrou
       capaz de saturar um link de internet a cabo.

  13.2. Preparac,ao

    1. Escolha um hostname unico. Ele nao tem que ser um hostname resolvivel
       publicamente (ele pode ser um nome em sua rede interna).

    2. Por padrao, a compilac,ao de pacotes necessita que as seguintes portas
       TCP estejam acessiveis: 22 (ssh), 414 (infoseek), e 8649 (ganglia). Se
       estas nao estiverem acessiveis, escolha outras e assegure-se de que um
       tunel ssh esteja configurado (veja abaixo).

       (Nota: se voce tem mais de uma maquina em seu site, voce vai precisar
       de uma porta TCP individual para cada servic,o em cada maquina, desta
       forma serao necessarios tuneis ssh. Portanto, voce provavelmente
       precisara configurar o redirecionamento de portas em seu firewall.)

    3. Decida se voce vai inicializar localmente ou via pxeboot. Voce vai
       descobrir que e mais facil acompanhar as mudanc,as do -current com a
       ultima opc,ao, especialmente se voce tem varias maquinas em seu site.

    4. Escolha um diretorio para manter as configurac,oes dos ports e os
       subdiretorios do chroot. Pode ser melhor coloca-los em uma partic,ao
       dedicada. (Por exemplo: /usr2/.)

  13.3. Configurando o src

    1. Crie um diretorio para armazenar a arvore dos fontes do ultimo
       -current e sincronize ela com o repositorio. (Uma vez que sua maquina
       provavelmente sera solicitada para compilar pacotes para o -current, o
       kernel que ela executa deve estar razoavelmente atualizado com o
       bindist que sera exportado por nossos scripts.)

    2. Se voce esta usando pxeboot: crie um diretorio para armazenar os
       arquivos de instalac,ao. Voce provavelmente vai querer usar um
       subdiretorio do /pxeroot, por exemplo, /pxeroot/${arch}-${branch}.
       Exporte como DESTDIR.

    3. Se voce esta realizando uma compilac,ao para outra plataforma, que nao
       a instalada na maquina (cross-building), exporte TARGET_ARCH=${arch}.

  Nota:

       O procedimento para compilac,ao cruzada de ports ainda nao esta
       definido.

    4. Gere um arquivo de configurac,ao para o kernel. Inclua o GENERIC (ou,
       se voce esta usando mais que 3.5G de memoria em um i386(TM), o PAE).

       Opc,ao requeridas:

 options         NULLFS
 options         TMPFS

       Opc,oes sugeridas:

 options         GEOM_CONCAT
 options         GEOM_STRIPE
 options         SHMMAXPGS=65536
 options         SEMMNI=40
 options         SEMMNS=240
 options         SEMUME=40
 options         SEMMNU=120

 options         ALT_BREAK_TO_DEBUGGER

       Para o PAE, atualmente nao e possivel carregar modulos. Portanto, se
       voce esta executando uma arquitetura que suporta emulac,ao binaria do
       Linux, voce precisara adicionar:

 options         COMPAT_LINUX
 options         LINPROCFS

       Tambem para o PAE, a partir de 12/09/2011 voce precisa do seguinte.
       Isso precisa ser investigado:

 nooption        NFSD                    # New Network Filesystem Server
 options         NFSCLIENT               # Network Filesystem Client
 options         NFSSERVER               # Network Filesystem Server

    5. Como root, execute os passos usuais de compilac,ao, por exemplo:

 make -j4 buildworld
 make buildkernel KERNCONF=${kernconf}
 make installkernel KERNCONF=${kernconf}
 make installworld

       Os passos de instalac,ao usam o caminho especificado na da variavel
       DESTDIR.

    6. Personalize os arquivos em etc/. O local no qual voce fara isso, se no
       proprio cliente ou em outra maquina, vai depender se voce esta usando
       ou nao o pxeboot.

       Se voce esta usando pxeboot: crie um subdiretorio no ${DESTDIR}
       chamado conf/. Crie um subdiretorio default/etc/, e (se seu site vai
       hospedar varios nos), subdiretorios ${ip-address}/etc/ para os
       arquivos que vao sobrescrever as configurac,oes para os hosts
       individuais. (Voce pode achar util criar um link simbolico de cada um
       destes diretorios para um hostname.) Copie todo o conteudo do
       ${DESTDIR}/etc/ para default/etc/; que e onde voce ira editar seus
       arquivos. Nos diretorios criados para cada enderec,o IP, voce
       provavelmente so ira necessitar personalizar os arquivos rc.conf.

       Em ambos os casos, execute os seguintes passos:

          * Crie um usuario e grupo ports-${arch}. Adicione o usuario ao
            grupo wheel. Ele pode ter um '*' no lugar da senha.

            Crie o /home/ports-${arch}/.ssh/ e popule o arquivo
            authorized_keys com as chaves ssh apropriadas.

          * Crie os usuarios:

 squid:*:100:100::0:0:User &:/usr/local/squid:/bin/sh
 ganglia:*:102:102::0:0:User &:/usr/local/ganglia:/bin/sh

            E tambem os adicione ao arquivo etc/group.

          * Crie os arquivos apropriados em etc/.ssh/.

          * Edite o etc/crontab e adicione o seguinte:

 *       *       *       *       *       root    /var/portbuild/scripts/client-metrics

          * Crie um etc/fstab apropriado. (Se voce tem varias maquinas
            diferentes, voce precisara colocar este arquivo nos diretorios
            especificos de cada uma.)

          * Edite o etc/inetd.conf e adicione o seguinte:

 infoseek        stream  tcp     nowait  nobody  /var/portbuild/scripts/reportload

          * Nos utilizamos o timezone UTC no cluster:

 cp /usr/share/zoneinfo/Etc/UTC etc/localtime

          * Crie um etc/rc.conf apropriado. (Se voce esta usando pxeboot, e
            tem varias maquinas diferentes, voce precisara colocar este
            arquivo nos diretorios especifico de cada uma.)

            Configurac,oes recomendadas para nos fisicos:

 hostname="${hostname}"
 inetd_enable="YES"
 linux_enable="YES"
 nfs_client_enable="YES"
 ntpd_enable="YES"
 ntpdate_enable="YES"
 ntpdate_flags="north-america.pool.ntp.org"
 sendmail_enable="NONE"
 sshd_enable="YES"
 sshd_program="/usr/local/sbin/sshd"

 gmond_enable="YES"
 squid_enable="YES"
 squid_chdir="/usr2/squid/logs"
 squid_pidfile="/usr2/squid/logs/squid.pid"

            Configurac,oes obrigatorias para nos baseados no VMWare:

 vmware_guest_vmmemctl_enable="YES"
 vmware_guest_guestd_enable="YES"

            Configurac,oes recomendadas para nos baseados no VMWare:

 hostname=""
 ifconfig_em0="DHCP"
 fsck_y_enable="YES"

 inetd_enable="YES"
 linux_enable="YES"
 nfs_client_enable="YES"
 sendmail_enable="NONE"
 sshd_enable="YES"
 sshd_program="/usr/local/sbin/sshd"

 gmond_enable="YES"
 squid_enable="YES"
 squid_chdir="/usr2/squid/logs"
 squid_pidfile="/usr2/squid/logs/squid.pid"

            O ntpd(8) nao deve ser habilitado para os nos baseados no VMWare.

            Alem disso, voce pode optar por deixar o squid desabilitado por
            padrao, de modo a nao ter um /usr2 persistente (o que deve
            economizar tempo na criac,ao da instancia.) O trabalho ainda esta
            em andamento.

          * Crie o etc/resolv.conf, se necessario.

          * Modifique o etc/sysctl.conf:

 9a10,30
 > kern.corefile=/usr2/%N.core
 > kern.sugid_coredump=1
 > #debug.witness_ddb=0
 > #debug.witness_watch=0
 >
 > # squid needs a lot of fds (leak?)
 > kern.maxfiles=40000
 > kern.maxfilesperproc=30000
 >
 > # Since the NFS root is static we don't need to check frequently for file changes
 > # This saves >75% of NFS traffic
 > vfs.nfs.access_cache_timeout=300
 > debug.debugger_on_panic=1
 >
 > # For jailing
 > security.jail.sysvipc_allowed=1
 > security.jail.allow_raw_sockets=1
 > security.jail.chflags_allowed=1
 > security.jail.enforce_statfs=1
 >
 > vfs.lookup_shared=1

          * Se desejar, modifique o etc/syslog.conf para mudar o destino dos
            logs para @pointyhat.freebsd.org.

  13.4. Configurando os ports

    1. Instale os seguintes ports:

 net/rsync
 security/openssh-portable (with HPN on)
 security/sudo
 sysutils/ganglia-monitor-core (with GMETAD off)
 www/squid (with SQUID_AUFS on)

       Existe um trabalho em andamento para criar um meta-port, mas ainda nao
       esta completo.

    2. Customize os arquivos em usr/local/etc/. O local no qual voce fara
       isso, se no proprio cliente ou em outra maquina, vai depender se voce
       esta usando ou nao o pxeboot.

  Nota:

       O truque de usar subdiretoriosconf para sobreescrever as opc,oes
       padroes e menos eficaz aqui, pois voce precisa copiar todos os
       subdiretorios do usr/. Este e um detalhe da implementac,ao de como o
       pxeboot funciona.

       Execute os seguintes passos:

          * Modifique o usr/local/etc/gmond.conf:

 21,22c21,22
 <   name = "unspecified"
 <   owner = "unspecified"
 ---
 >   name = "${arch} package build cluster"
 >   owner = "portmgr@FreeBSD.org"
 24c24
 <   url = "unspecified"
 ---
 >   url = "http://pointyhat.freebsd.org"

            Se existirem maquinas de mais de um cluster no mesmo dominio
            multicast (basicamente = LAN), entao altere os grupos de
            multicast para valores diferentes (.71, .72, etc).

          * Crie o usr/local/etc/rc.d/portbuild.sh, usando um valor
            apropriado para scratchdir:

 #!/bin/sh
 #
 # Configure a package build system post-boot

 scratchdir=/usr2

 ln -sf ${scratchdir}/portbuild /var/

 # Identify builds ready for use
 cd /var/portbuild/${arch}
 for i in */builds/*; do
     if [ -f ${i}/.ready ]; then
         mkdir /tmp/.setup-${i##*/}
     fi
 done

 # Flag that we are ready to accept jobs
 touch /tmp/.boot_finished

          * Modifique o usr/local/etc/squid/squid.conf:

 288,290c288,290
 < #auth_param basic children 5
 < #auth_param basic realm Squid proxy-caching web server
 < #auth_param basic credentialsttl 2 hours
 ---
 > auth_param basic children 5
 > auth_param basic realm Squid proxy-caching web server
 > auth_param basic credentialsttl 2 hours
 611a612
 > acl localnet src 127.0.0.0/255.0.0.0
 655a657
 > http_access allow localnet
 2007a2011
 > maximum_object_size 400 MB
 2828a2838
 > negative_ttl 0 minutes

            Modifique tambem o usr/local para usr2 em cache_dir, access_log,
            cache_log, cache_store_log, pid_filename, netdb_filename,
            coredump_dir.

            E finalmente, mude o esquema de armazenamento do cache_dir, de
            ufs para aufs (o qual oferece uma melhor performance).

          * Configure o ssh: copie os arquivos do /etc/ssh para
            /usr/local/etc/ssh e adicione NoneEnabled yes ao sshd_config.

          * Modifique o usr/local/etc/sudoers:

 38a39,42
 >
 > # local changes for package building
 > %wheel        ALL=(ALL) ALL
 > ports-${arch}    ALL=(ALL) NOPASSWD: ALL

  13.5. Configurac,ao no proprio cliente

    1. Entre no diretorio port/package que voce escolheu acima, por exemplo,
       cd /usr2.

    2. Execute como root:

 mkdir portbuild
 chown ports-${arch}:ports-${arch} portbuild
 mkdir pkgbuild
 chown ports-${arch}:ports-${arch} pkgbuild
 mkdir squid
 mkdir squid/cache
 mkdir squid/logs
 chown -R squid:squid squid

    3. Se os clientes preservam o conteudo do /var/portbuild entre as suas
       inicializac,oes, entao eles tambem deverao preservar o /tmp ou entao
       revalidar as compilac,oes disponiveis no momento do boot (veja o
       script nas maquinas amd64). Eles tambem devem limpar os chroots
       obsoletos das compilac,oes anteriores antes de criar o
       /tmp/.boot_finished.

    4. Inicie o cliente.

    5. Como root, crie a estrutura de diretorios do squid:

 squid -z

  13.6. Configurac,ao no pointyhat

   Estes passos precisam ser feitos por um portmgr, autenticado como o
   usuario ports-${arch}, no pointyhat.

    1. Se alguma das portas TCP padrao nao estiver disponivel (veja acima),
       voce precisara criar um tunel ssh para ela e devera inclui-lo no
       crontab.

    2. Adicione uma entrada em /home/ports-${arch}/.ssh/config para
       especificar o enderec,o IP publico, a porta TCP para o ssh, o usuario,
       e qualquer outra informac,ao necessaria.

    3. Crie o /var/portbuild/${arch}/clients/bindist-${hostname}.tar.

          * Copie um arquivos dos existentes para usar como modelo e
            descompacte-o em um diretorio temporario.

          * Personalize o etc/resolv.conf para o site local.

          * Personalize o etc/make.conf para a busca de arquivo no FTP local.
            Nota: a anulac,ao da variavel MASTER_SITE_BACKUP deve ser comum
            para todos os nos, mas a primeira entrada em MASTER_SITE_OVERRIDE
            deve ser o espelho FTP mais proximo. Por exemplo:

 .if defined(FETCH_ORIGINAL)
 MASTER_SITE_BACKUP=
 .else
 MASTER_SITE_OVERRIDE= \
         ftp://friendly-local-ftp-mirror/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/ \
         ftp://${BACKUP_FTP_SITE}/pub/FreeBSD/distfiles/${DIST_SUBDIR}/
 .endif

          * Empacote-o com tar e mova para o local correto.

       Dica: voce precisara de um destes para cada maquina; no entanto, se
       voce tem varias maquinas no mesmo site, voce deve criar um local
       especifico para este site (por exemplo, em
       /var/portbuild/conf/clients/) e criar um link simbolico para ele.

    4. Crie o /var/portbuild/${arch}/portbuild-${hostname} utilizando um dos
       existentes como guia. O conteudo deste arquivo sobrescreve as
       configurac,oes de /var/portbuild/${arch}/portbuild.conf.

       Sugestao de valores:

 disconnected=1
 http_proxy="http://localhost:3128/"
 squid_dir=/usr2/squid
 scratchdir=/usr2/pkgbuild
 client_user=ports-${arch}
 sudo_cmd="sudo -H"
 rsync_gzip=-z

 infoseek_host=localhost
 infoseek_port=${tunelled-tcp-port}

       Outros valores possiveis:

 use_md_swap=1
 md_size=9g
 use_zfs=1
 scp_cmd="/usr/local/bin/scp"
 ssh_cmd="/usr/local/bin/ssh"

   Os passos abaixo precisam ser executados por um portmgr autenticado como
   root no pointyhat.

    1. Adicione o enderec,o IP publico em /etc/hosts.allow. (Lembre-se,
       varias maquinas podem estar sob o mesmo enderec,o IP.)

    2. Adicione uma entrada data_source para /usr/local/etc/gmetad.conf:

       data_source "arch/location Package Build Cluster" 30 hostname

       Voce precisara reiniciar o gmetad.

  13.7. Habilitando o no

   Estes passos precisam ser executados por um portmgr autenticado como
   ports-arch no pointyhat.

    1. Certifique-se que o ssh esta funcionando executando ssh hostname.

    2. Crie os arquivos em /var/portbuild/scripts/ executando algo como
       /var/portbuild/scripts/dosetupnode arch major latest hostname.
       Verifique se os arquivos foram criados no diretorio.

    3. Teste as outras portas TCP executando telnet hostname portnumber. A
       porta 414 (ou seu tunel) deve dar-lhe algumas linhas com informac,oes
       de status, incluindo arch e osversion; A porta 8649 deve retornar um
       XML do ganglia.

   Esses passos precisam ser executados por um portmgr autenticado como root
   no pointyhat.

     * Informe o qmanager sobre o no. Por exemplo:

       python path/qmanager/qclient add name=uniquename arch=arch
       osversion=osversion numcpus=number haszfs=0 online=1 domain=domain
       primarypool=package pools="package all" maxjobs=1
       acl="ports-arch,deny_all"

14. Como configurar um novo branch do FreeBSD

   Quando um novo branch e criado, e necessario efetuar alguns ajustes no
   sistema para especificar que o branch anterior nao mais corresponde ao
   HEAD. As seguintes instruc,oes se aplicam ao numero do branch anterior:

     * (novo codigo base) Edite o /var/portbuild/conf/server.conf e fac,a as
       seguintes alterac,oes:

          * Adicione o new-branch na variavel SRC_BRANCHES.

          * Para o branch que anteriormente era o head, mude o
            SRC_BRANCH_branch_TAG para RELENG_branch_0.

          * Adicione SRC_BRANCH_new-branch_TAG=. (o ponto e literal).

     * (novo codigo base) Execute o /var/portbuild/updatesnap manualmente.

     * (Apenas para o antigo codigo base) Crie um novo sistema de arquivos
       zfs para os fontes:

 zfs create a/snap/src-branch

     * (Necessario apenas para o antigo codigo base): Obtenha uma copia da
       arvore de fontes do src apartir do SVN e deposite a mesma no novo
       sistema de arquivos:

 cvs -Rq -d /r/ncvs co -d src-branch-r RELENG_branch

     * (Necessario apenas para o antigo codigo base): Edite a copia principal
       do Tools/portbuild/portbuild.conf.

     * (Necessario apenas para o antigo codigo base): Edite a copia do
       arquivo acima para cada uma das arquiteturas em
       /var/portbuild/arch/portbuild.conf.

     * (Necessario apenas para o antigo codigo base): Edite o
       /var/portbuild/scripts/buildenv.

     * (Necessario apenas para o antigo codigo base): Adicione um link
       simbolico de /var/portbuild/scripts/dopackages para
       /var/portbuild/scripts/dopackages.branch.

     * (Necessario apenas para o antigo codigo base): Modifique as variaveis
       HEAD_BRANCH e NON_HEAD_BRANCHES no arquivo
       /var/portbuild/scripts/updatesnap.

     * (Necessario apenas para o antigo codigo base): Adicione o diretorio
       snap ao arquivo /var/portbuild/scripts/zexpire.

     * (Necessario apenas para o antigo codigo base): Crie os links
       simbolicos para uso do servidor web no diretorio
       /var/portbuild/errorlogs/:

 ln -s ../arch/branch/builds/latest/bak/errors arch-branch-full
 ln -s ../arch/branch/builds/latest/bak/logs arch-branch-full-logs
 ln -s ../arch/branch/builds/latest/errors arch-branch-latest
 ln -s ../arch/branch/builds/latest/logs arch-branch-latest-logs
 ln -s ../arch/branch/builds/latest/bak/packages arch-branch-packages-full
 ln -s ../arch/branch/builds/latest/packages arch-branch-packages-latest

     * Inicie a compilac,ao para o branch executando:

 build create arch branch

     * Crie o bindist.tar.

15. Como excluir um branch que deixou de ser suportado pelo FreeBSD

   Quando um branch antigo deixa de ser suportado, existem algumas coisas a
   serem feitas para que nao fique sujeira para tras.

     * (novo codigo base) Edite o /var/portbuild/conf/server.conf e fac,a as
       seguintes alterac,oes:

          * Apague o old-branch da variavel SRC_BRANCHES.

          * Remova o SRC_BRANCH_old-branch_TAG =whatever

     * (novo e antigo codigo base): umount a/snap/src-old-branch/src; umount
       a/snap/src-old-branch; zfs destroy -r a/snap/src-old-branch

     * (novo e antigo codigo base) Provavelmente voce encontrara os seguintes
       arquivos e links simbolicos em /var/portbuild/errorlogs/ os quais
       podem ser removidos:

          * Arquivos chamados *-old_branch-failure.html

          * Arquivos chamados buildlogs_*-old_branch-*-logs.txt

          * Links simbolicos chamados *-old_branch-previous*

          * Links simbolicos chamados *-old_branch-latest*

16. Como regerar pacotes baseados em outra versao menor do FreeBSD

   Desde 2011 a filosofia da compilac,ao de pacotes diz que devemos
   compila-los baseados na versao mais antiga suportada de cada branch. Por
   exemplo: se no RELENG-8 as seguintes versoes sao suportadas: 8.1, 8.2,
   8.3; entao o packages-8-stable deve ser compilado a partir da versao 8.1.

   Quando uma versao chega ao fim de sua vida (End-Of-Life, veja o quadro),
   uma compilac,ao completa (nao incremental!) dos pacotes deve ser realizada
   e enviada para os servidores de distribuic,ao.

   Os procedimentos para o novo codigo base sao os que seguem abaixo:

     * Edite o /var/portbuild/conf/server.conf e fac,a as seguintes
       mudanc,as:

          * Altere o SRC_BRANCH_branch_TAG para RELENG_branch_N no qual o N e
            versao menor mais antiga para este ramo.

     * Execute o /var/portbuild/updatesnap manualmente.

     * Execute o dopackages com a opc,ao -nobuild.

     * Siga os procedimentos de configurac,ao.

     * Agora voce ja pode executar o dopackages sem a opc,ao -nobuild.

   O procedimento para o antigo codigo base fica como um exercicio para o
   leitor.

17. Como configurar uma nova arquitetura

  Nota:

   Os passos iniciais precisam ser feitos usando sudo.

     * Crie um novo usuario e grupo ports-arch.

     * mkdir /var/portbuild/arch

     * Crie um novo sistema de arquivo zfs:

 zfs create -o mountpoint=/a/portbuild/arch a/portbuild/arch

     * chown ports-arch:portmgr /var/portbuild/arch;
 chmod 755 /var/portbuild/arch;
 cd /var/portbuild/arch

     * Crie e popule o diretorio .ssh.

     * Crie um diretorio para os logs de compilac,ao e para os logs de erros:

 mkdir /dumpster/pointyhat/arch/archive

  Nota:

       E possivel que /dumpster/pointyhat nao tenha mais espac,o suficiente.
       Neste caso, crie o diretorio dos arquivos como
       /dumpster/pointyhat/arch/archive e crie um link simbolico para ele.
       (Isso precisa ser resolvido.)

     * Crie um link para o diretorio acima para o servidor web:

 ln -s /dumpster/pointyhat/arch/archive archive

  Nota:

   Os proximos passos sao mais faceis de serem realizados como o usuario
   ports-arch.

     * No diretorio /var/portbuild/arch execute:

 mkdir clients

     * Popule o diretorio clients como de costume.

     * mkdir loads

     * mkdir lockfiles

     * Crie um make.conf local. Nos casos mais comuns voce pode executar:

 ln ../make.conf ./make.conf

     * Crie um arquivo vazio mlist.

     * (Necessario apenas para o antigo codigo base) Crie o pnohang.arch. (O
       modo mais facil e fazer isso em um cliente, e depois copiar o arquivo
       de volta):

 cc pnohang.c -o pnohang-arch

     * Crie um novo arquivo portbuild.conf a partir de um existente para uma
       outra arquitetura.

     * Crie os arquivos portbuild.machinename.conf personalizando-os de forma
       adequada.

     * cd .ssh && ssh-keygen

     * Edite o arquivo .ssh/config para tornar mais conveniente o uso do ssh.

     * Crie o diretorio de configurac,ao privada:

 mkdir /var/portbuild/conf/arch

     * Crie os scripts dotunnel.* que forem necessarios dentro do diretorio
       acima.

  Nota:

   Mais uma vez usando sudo:

     * Informe o qmanager sobre a arquitetura:

 python path/qmanager/qclient add_acl name=ports-arch uidlist=ports-arch gidlist=portmgr sense=1

     * (Necessario apenas para o novo codigo base): Adicione a arch na
       variavel SUPPORTED_ARCHS do arquivo /var/portbuild/arch/server.conf.

     * (Necessario apenas para o antigo codigo base): Edite o
       /var/portbuild/scripts/buildenv.

     * Adicione o diretorio arch no /var/portbuild/scripts/zbackup e no
       /var/portbuild/scripts/zexpire.

     * Necessario apenas para o antigo codigo base): Como no procedimento
       para criac,ao de um novo branch: crie os links para o servidor web no
       diretorio /var/portbuild/errorlogs/:

 ln -s ../arch/branch/builds/latest/bak/errors arch-branch-full
 ln -s ../arch/branch/builds/latest/bak/logs arch-branch-full-logs
 ln -s ../arch/branch/builds/latest/errors arch-branch-latest
 ln -s ../arch/branch/builds/latest/logs arch-branch-latest-logs
 ln -s ../arch/branch/builds/latest/bak/packages arch-branch-packages-full
 ln -s ../arch/branch/builds/latest/packages arch-branch-packages-latest

     * Crie mais dois links simbolicos para o servidor web dentro do
       diretorio /var/portbuild/errorlogs/:

 ln -s ../arch/archive/buildlogs arch-buildlogs
 ln -s ../arch/archive/errorlogs arch-errorlogs

  Nota:

   Novamente como ports-arch:

     * Para cada branch que sera suportado, fac,a o seguinte:

          * Inicie a compilac,ao para o branch com:

 build create arch branch

          * Crie o bindist.tar.

  Nota:

   Uma ultima vez usando o sudo:

     * (Necessario apenas para o antigo codigo base): So depois que a
       primeira execuc,ao do dopackages for feita para a arquitetura:
       adicione a arquitetura ao /var/portbuild/scripts/dopackagestats.

     * Adicione uma entrada arch apropriada para o
       /var/portbuild/scripts/dologs no crontab do usuario root. (Esta e uma
       soluc,ao paliativa)

18. Como configurar um novo no principal (instancia do pointyhat)

   Esta sec,ao esta em progresso.

   Por favor, consulte o Mark Linimon antes de efetuar qualquer mudanc,a.

  18.1. Instalac,ao basica

    1. Instale o FreeBSD.

    2. Para cada arquitetura suportada, adicione um usuario e grupo
       ports-${arch}. Adicione os usuarios ao grupo wheel. Eles devem ter um
       '*' como senha. Crie tambem, de modo similar, o usuario ports e
       portmgr.

    3. Para cada arquitetura suportada, crie o /home/ports-${arch}/.ssh/ e
       popule o authorized_keys.

    4. Crie os arquivos apropriados em /etc/.ssh/.

    5. Adicione a seguinte linha ao arquivo /boot/loader.conf:

 console="vidconsole,comconsole"

    6. Adicione as seguintes linhas ao arquivo /etc/sysctl.conf:

 kern.maxfiles=40000
 kern.maxfilesperproc=38000

    7. Certifique-se de que as seguintes mudanc,as foram realizadas no
       /etc/ttys:

 ttyu0   "/usr/libexec/getty std.9600"   vt100   on secure

    8. Ainda a ser definido.

  18.2. Configurando o disco

    1. Crie um volume zfs chamado a e monte-o em /a:

 # zpool create a mirror da1 da2 mirror da3 da4 mirror da5 da6 mirror da7 da8

    2. Configure o diretorio base do portbuild:

 # mkdir -p /a/portbuild
 # cd /a/portbuild
 # chown portmgr:portmgr .
 # chmod 775 .

    3. Ainda a ser definido.

  18.3. Configurando o src

     * Ainda a ser definido.

  18.4. Configurando o ports

    1. Os seguintes ports (ou seus sucessores mais recentes) sao
       obrigatorios:

 databases/py-pysqlite23
 databases/py-sqlalchemy
 devel/git (WITH_SVN)
 devel/py-configobj
 devel/py-setuptools
 devel/subversion
 net/nc
 net/rsync
 sysutils/ganglia-monitor-core (with GMETAD off)
 sysutils/ganglia-webfrontend (WITHOUT_X11)
 www/apache22 (with EXT_FILTER and THREADS)

       Os ports acima tambem irao instalar:

 databases/sqlite3
 lang/perl-5.12
 lang/python27

       Os seguintes ports (ou seus sucessores mais recentes) sao fortemente
       recomendados:

 benchmarks/bonnie++
 devel/ccache
 mail/postfix
 net/isc-dhcp41-server
 ports-mgmt/pkg_cutleaves
 ports-mgmt/pkg_tree
 ports-mgmt/portaudit
 ports-mgmt/portmaster
 security/sudo
 shells/bash
 shells/zsh
 sysutils/screen
 sysutils/smartmontools

    2. Configure o e-mail fazendo o seguinte: (ainda a ser definido).

  18.5. Outros

     * Ainda a ser definido.

19. Procedimentos para lidar com falhas de disco

   Quando uma maquina tem uma falha de disco (por exemplo, um panic devido a
   erros de leitura, etc.), devemos executar os seguintes procedimentos:

     * Anote o tempo e o tipo de falha (por exemplo, colea saida do console
       que for relevante) no /var/portbuild/${arch}/reboots

     * Para os clientes gohan i386, limpe o disco criando o arquivo /SCRUB no
       nfsroot (por exemplo, /a/nfs/8.dir1/SCRUB) e reinicie. Isso vai
       executar um dd if=/dev/zero of=/dev/ad0 e forc,ar a unidade a remapear
       todos os setores defeituosos que encontrar, isto se ela ainda tiver
       setores suficientes sobrando. Esta e uma medida temporaria para
       estender o tempo de vida de uma unidade de disco que em breve ira
       tornar-se inutilizavel.

  Nota:

       Para os sistemas blade i386, outro sinal de falha nos discos e quando
       a blade fica em espera e nao responde a qualquer comando pelo console,
       ou mesmo pelo NMI.

       Para os outros sistemas de compilac,ao que nao executam um newfs nos
       seus discos no momento da inicializac,ao (por exemplo, os sistemas
       amd64) este procedimento deve ser ignorado.

     * Se o problema persistir, entao provavelmente o disco esta inutilizado.
       Remova a maquina do mlist e (para discos ATA) execute o smartctl na
       unidade:

 smartctl -t long /dev/ad0

       Isso vai levar cerca de 30 minutos:

 gohan51# smartctl -t long /dev/ad0
 smartctl version 5.38 [i386-portbld-freebsd8.0] Copyright (C) 2002-8
 Bruce Allen
 Home page is http://smartmontools.sourceforge.net/

 === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
 Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
 Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
 Testing has begun.
 Please wait 31 minutes for test to complete.
 Test will complete after Fri Jul  4 03:59:56 2008

 Use smartctl -X to abort test.

       Quando o comando acima finalizar, execute o comando smartctl -a
       /dev/ad0 para verificar o estado da unidade:

 # SMART Self-test log structure revision number 1
 # Num  Test_Description    Status                  Remaining
 LifeTime(hours)  LBA_of_first_error
 #   1  Extended offline    Completed: read failure       80%     15252    319286

       Ele tambem exibira outros dados, incluindo um log dos erros anteriores
       da unidade. E possivel que a unidade mostre erros de DMA embora nao
       apresente falhas no auto-teste (por conta do remapeamento de setores).

   Quando um disco falhar, por favor, informe os administradores do cluster,
   para que possamos substitui-lo.
