Procedimentos para Construção de Pacotes

1 Introdução

Com o objetivo de disponibilizar binários pré-compilados de aplicações de terceiros para o FreeBSD, a Coleção de Ports é regularmente compilada em um dos “Clusters de Compilação de Pacotes”. Atualmente o principal cluster em uso é o http://pointyhat.FreeBSD.org.

Este artigo documenta os trabalhos internos do cluster

2 Gerenciamento dos Clientes de Compilação

Os clientes i386 localizados conjuntamente com o pointyhat, efetuam o boot via rede a partir dele (nós conectados); todos os outros clientes (nós desconectados) ou são 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, através do rsync, os dados necessários (a árvore de ports e dos fontes, bindist tarballs, scripts, etc.) para os nós desconectados durante a fase de configuração dos nós. Em seguida, o diretório portbuild desconectado é montado como nullfs para compilações sob chroot.

O usuário ports-${arch} pode acessar os nós clientes através do ssh(1) para monitorá-los. Use o sudo e verifique o portbuild.hostname.conf para o usuário e detalhes do acesso.

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

O script scripts/checkmachines é usado para monitorar a carga em todos os nós do cluster de compilação, e agendar quais nós compilarão quais ports. Este script não é muito robusto e tem uma tendência a morrer. É melhor iniciar este script no nó principal (por exemplo, pointyhat) depois do boot usando um loop com while(1).

3 Configuração do Ambiente de Compilação sob Chroot

A compilação de pacotes é 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 árvore de diretórios em ${arch}/${branch}/builds/${buildid}/src/ e o instala em ${worlddir}. A árvore de diretórios será atualizada primeiro, a menos que a opção -nocvs seja especificada.

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

O arquivo bindist.tar é 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 máquina estão localizados em ${arch}/clients.

O arquivo bindist.tar é extraído para cada cliente durante a inicialização dos mesmos, e no início de cada passagem do script dopackages.

4 Customizando Sua Compilação

(O trecho a seguir aplica-se apenas ao novo código base.)

Você pode customizar sua compilação providenciando versões 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 serão usados, em vez dos arquivos padrões que estão no lado do servidor.

Da mesma forma, se você também quiser afetar o make.conf no lado do cliente, você pode usar o ${arch}/${branch}/builds/${buildid}/make.conf.client.

RUBY_DEFAULT_VER= 1.9

.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=

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

WITH_PKGNG=yes

WITH_BSD_SORT=yes

5 Iniciando a Compilação

Várias compilações separadas para cada arquitetura - a combinação de branchs é suportada. Todos os dados privados para uma compilação (árvore de ports, árvore do src, pacotes, distfiles, arquivos de log, bindist, Makefile, etc) estão localizados sob ${arch}/${branch}/builds/${buildid}. Alternativamente, a última compilação pode ser referenciada sob o buildid latest, e a anterior a esta é chamada previous.

Novas compilações são clonadas a partir da latest, o que é rápido, uma vez que ele usa ZFS.

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

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

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

6 Anatomia de uma compilação

Uma compilação completa, sem qualquer opção -no que desabilite as opções padrões, executa as seguintes operações na ordem especificada:

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

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

3. Verifica se ports não têm uma entrada SUBDIR no Makefile de suas respectivas categorias [*]

4. Cria o arquivo duds, que é uma lista de ports que não precisam ser compilados [*] [+]

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

6. Define os nós que serão usados na compilação [*] [+]

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

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

9. Executa outra configuração do nó [+]

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 está rodando.

[+] Se qualquer destes passos falhar, a compilação será encerrada.

[++] O status destes passos pode ser encontrado em ${arch}/${branch}/make (antigo código base) ou ${arch}/${branch}/journal (novo código base). Ports individuais irão escrever seus logs de compilação em ${arch}/${branch}/logs e os seus logs de erros em ${arch}/${branch}/errors.

Anteriormente, a árvore docs também era verificada, no entanto, isso se mostrou desnecessário.

7 Manutenção da Compilação

Existem vários casos onde você precisará limpar manualmente uma compilação:

1. Você a interrompeu manualmente.

2. O pointyhat foi reiniciado enquanto uma compilação estava executando.

3. O qmanager falhou e reiniciado

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

ssh -l root gohan24 df

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

8 Monitorando a Compilação

Você pode usar o comando qclient para monitorar o status dos nós de compilação, e para listar as tarefas de compilação agendadas para execução:

python path/qmanager/qclient jobs

python path/qmanager/qclient status

O comando scripts/stats ${branch} mostra o número de pacotes cuja compilação já finalizou.

A execução de um cat /var/portbuild/*/loads/* irá mostrar o load nos clientes e o número de compilações simultâneas em andamento. Os arquivos que foram atualizados recentemente correspondem aos clientes que estão online; os demais arquivos são dos clientes que estão offline.

Executar tail -f ${arch}/${branch}/build.log irá mostrar o progresso geral da compilação.

Se a compilação do port falhar, e o motivo não ficar imediatamente óbvio a partir da análise do log, você pode preservar o WRKDIR para uma análise mais aprofundada. Para fazer isso, crie um arquivo vazio chamado .keep no diretório do port, isso vai arquivar, comprimir, e copiar o WRKDIR para ${arch}/${branch}/wrkdirs.

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

Se todas as compilações iniciam reclamando de que não pode carregar os pacotes dos quais ela depende, verifique se o httpd ainda está rodando, e o i reinicie se não estiver.

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

O status de todas as compilações é gerado duas vezes por hora e postado em http://pointyhat.FreeBSD.org/errorlogs/packagestats.html. Para cada buildenv é apresentado o seguinte:

• cvs date é o conteúdo do cvsdone. É por isso que nós recomendamos que você atualize o cvsdone para executar compilações experimentais, -exp (veja abaixo).

• data do último log (latest log)

• número de linhas no INDEX

• o número atual de logs de compilações (build logs)

• o número de pacotes concluídos (packages)

• o número de erros (errors)

• o número de ports ignorados (duds) (listados como skipped)

• A coluna missing mostra a diferença entre o INDEX e as outras colunas. Se você reiniciou uma compilação após um cvs update, provavelmente haverá duplicatas nos pacotes e colunas de erros, e esta coluna será inútil. (O script é ingênuo).

• Os valores das colunas running e completed são palpites baseados em um grep(1) do build.log.

9 Lidando com Erros de Compilação

A maneira mais fácil de rastrear falhas na compilação é receber os logs enviados por e-mail e organizá-los em uma pasta, assim você pode manter uma lista com as falhas atuais e detectar facilmente as novas. Para fazer isto, adicione um endereço de e-mail ao ${branch}/portbuild.conf. Você pode encaminhar facilmente os novos erros para os mantenedores.

Quando um port passa a não compilar corretamente durante varios ciclos de compilação seguidos, é hora de marcá-lo como quebrado (BROKEN). Recomenda-se notificar os mantenedores durante duas semanas, antes de fazê-lo.

10 Compilando Pacotes para uma Versão Específica

Ao compilar pacotes para uma versão específica do FreeBSD, pode ser necessário atualizar manualmente as árvores do ports e do src para a tag da versão desejada e usar as opções -nocvs e -noportscvs.

Para compilar conjuntos de pacotes que serão usados em um CD-ROM, use a opção -cdrom para o comando dopackages.

Se não houver espaço em disco disponível no cluster, use -nodistfiles para que os distfiles não sejam baixados.

Após completar a compilação inicial, reinicie a compilação com -restart -fetch-original para baixar os distfiles atualizados. Então, uma vez que a compilação tiver sido pós-processada, faça um inventário da lista de arquivos baixados:

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

Este arquivo de inventário normalmente fica localizado em i386/${branch} no nó principal do cluster.

Isto é útil para ajudar na limpeza periódica dos distfiles do ftp-master. Quando o espaço se torna escasso, os distfiles das versões 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 versão final deve ser criado. Para se assegurar, execute manualmente o script ${arch}/${branch}/cdrom.sh para certificar-se de que todos os pacotes com distribuição restrita via CD-ROM e todos os distfiles foram removidos. Então, copie o diretório ${arch}/${branch}/packages para ${arch}/${branch}/packages-${release}. Uma vez que os pacotes tenham sido movidos com segurança, contate o Time de engenharia de Lançamento <re@FreeBSD.org> e informe-os da localização dos pacotes do release.

Lembre-se de coordenar com o Time de engenharia de Lançamento <re@FreeBSD.org> sobre o timing e o status das compilações do release.

11 Upload dos Pacotes

Uma vez que a compilação 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 compilação foi executada com a opção -nofinish, então certifique-se de executar em seguida o comando dopackages -finish para realizar o pós-processamento dos pacotes (remover pacotes marcados como RESTRICTED ou como NO_CDROM onde for apropriado, remover pacotes não listados no INDEX, remover do INDEX as referências para pacotes não compilados, e gerar um sumário CHECKSUM.MD5); e dos distfiles (movê-los do diretório temporário distfiles/.pbtmp para o diretório distfiles/ e remover os distfiles marcados como RESTRICTED e NO_CDROM).

É recomendado que se execute manualmente os scripts restricted.sh e/ou cdrom.sh após a finalização do dopackages, apenas por seguranç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 subdiretórios de pacotes são nomeados de acordo com a versão e branch ao qual se destinam. Por exemplo:

• packages-7.2-release

• packages-7-stable

• packages-8-stable

• packages-9-stable

• packages-10-current

Se você está preparando um conjunto de pacotes completamente novo (por exemplo, para um novo release), copie os pacotes para a área 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/ é apenas um atalho.)

Para compilações incrementais, o upload deve ser feito usando o rsync para não colocar muita pressão nos espelhos.

SEMPRE use o rsync primeiro com a opção -n e verifique a saída do comando para assegurar-se que não existem problemas. Se parece estar tudo bem, execute novamente o rsync sem a opção -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 execução manual deste processo é um procedimento obsoleto.

12 Compilação de Patches Experimentais

Compilações de patches experimentais são executadas de tempos em tempos para novas funções ou correções de defeitos na infraestrutura do ports (isto é, bsd.port.mk), ou para testar atualizações em grande escala. A qualquer momento podem haver vários patches de branchs experimentais simultâneos, como o 8-exp na arquitetura amd64.

Geralmente, a compilação de patches experimentais é executada da mesma forma que qualquer outra compilação, exceto que você deve primeiro atualizar a árvore de ports para a última versão e, em seguida, aplicar os seus patches. Para fazer o primeiro, você pode usar o seguinte:

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

Essa é a simulação mais próxima do que o script dopackages faz. (Embora o cvsdone seja meramente informativo, ele pode ser útil.)

Você precisará editar o update.out para procurar por linhas que comecem com ^M, ^C, ou ^? para que possa corrigi-las.

É sempre uma boa idéia salvar cópias do original de todos os arquivos modificados, bem como uma lista do que você está modificando. Você pode consultar a lista ao fazer o commit final, para se certificar de que você está realizando o commit exatamente daquilo que testou.

Pelo fato da máquina ser compartilhada, alguém pode excluir suas alterações por engano, então mantenha cópias destas, por exemplo, no seu diretório home freefall freefall. Não use o tmp/; pois a pointyhat executa ele mesmo alguma versão do -CURRENT, você pode esperar por reinicializações (no mínimo para atualizações).

Para que você tenha uma compilação de controle com a qual possa comparar eventuais falhas, você deve primeiro executar a compilação de pacote no branch em que os patches experimentais foram baseados para a arquitetura i386 (atualmente esta é o 8). Quando estiver preparando a compilação dos patches experimentais, faça o checkout da árvore do ports e do src com a mesma data da que foi usada para a compilação de controle. Isso vai garantir uma comparação válida entre as compilações depois.

Uma vez terminada a compilação, compare as falhas da compilação de controle com as da compilação 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

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

Este último comando vai gerar um relatório com duas colunas. A primeira coluna contém os ports que falharam na compilação de controle, mas não na compilação com patches experimentais; a segunda é o inverso As razões para o port estar na primeira coluna incluem:

• O port foi corrigido desde que a compilação de controle foi executada, ou foi atualizado para uma nova versão que também está quebrada (assim a nova versão também deve aparecer na segunda coluna)

• O port foi corrigido pelos patches experimentais na compilação experimental

• O port não foi compilado na compilação com patches experimentais devido a falha de uma dependência

Razões para o port aparecer na segunda coluna incluem:

• O port foi quebrado pelos patches experimentais [1]

• O port foi atualizado desde a compilação de controle e deixou de compilar [2]

• O port foi quebrado devido a um erro temporário (por exemplo, site FTP fora do ar, erro do pacote cliente, etc.)

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

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

O seguinte comando vai configurar o branch de controle para a compilação parcial (antigo código base):

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

As compilações devem ser executadas a partir do diretório packages/All. Este diretório deve estar vazio inicialmente, exceto pelo link simbólico do Makefile. Se este link simbólico não existir, ele deve ser criado:

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

Isto vai compilar apenas os pacotes listados, bem como todas as suas dependências.

Você pode verificar o progresso da compilação parcial da mesma forma que você faria com uma compilação normal.

Uma vez que todos os erros tenham sido resolvidos, você pode efetuar o commit do conjunto de pacotes. Após efetuar o commit, é de costume enviar um e-mail para ports@FreeBSD.org e com cópia para ports-developers@FreeBSD.org, informando as pessoas sobre as mudanças. Um resumo de todas as mudanças também deve registrado no arquivo /usr/ports/CHANGES.

13 Como configurar um novo nó de compilação de pacotes

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

14 Como configurar um novo branch do FreeBSD

Quando um novo branch é criado, é necessário efetuar alguns ajustes no sistema para especificar que o branch anterior não mais corresponde ao HEAD. As seguintes instruções se aplicam ao número do branch anterior:

• (novo código base) Edite o /var/portbuild/conf/server.conf e faça as seguintes alterações:

  • Adicione o new-branch na variável 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 é literal).

• (novo código base) Execute o /var/portbuild/updatesnap manualmente.

• (Apenas para o antigo código base) Crie um novo sistema de arquivos zfs para os fontes:

  zfs create a/snap/src-branch
  

• (Necessário apenas para o antigo código base): Obtenha uma cópia da árvore 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
  

• (Necessário apenas para o antigo código base): Edite a cópia principal do Tools/portbuild/portbuild.conf.

• (Necessário apenas para o antigo código base): Edite a cópia do arquivo acima para cada uma das arquiteturas em /var/portbuild/arch/portbuild.conf.

• (Necessário apenas para o antigo código base): Edite o /var/portbuild/scripts/buildenv.

• (Necessário apenas para o antigo código base): Adicione um link simbólico de /var/portbuild/scripts/dopackages para /var/portbuild/scripts/dopackages.branch.

• (Necessário apenas para o antigo código base): Modifique as variáveis HEAD_BRANCH e NON_HEAD_BRANCHES no arquivo /var/portbuild/scripts/updatesnap.

• (Necessário apenas para o antigo código base): Adicione o diretório snap ao arquivo /var/portbuild/scripts/zexpire.

• (Necessário apenas para o antigo código base): Crie os links simbólicos para uso do servidor web no diretório /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 compilação 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 não fique sujeira para trás.

• (novo código base) Edite o /var/portbuild/conf/server.conf e faça as seguintes alterações:

  • Apague o old-branch da variável SRC_BRANCHES.

  • Remova o SRC_BRANCH_old-branch_TAG =whatever

• (novo e antigo código 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 código base) Provavelmente você encontrará os seguintes arquivos e links simbólicos em /var/portbuild/errorlogs/ os quais podem ser removidos:

  • Arquivos chamados *-old_branch-failure.html

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

  • Links simbólicos chamados *-old_branch-previous*

  • Links simbólicos chamados *-old_branch-latest*

16 Como regerar pacotes baseados em outra versão menor do FreeBSD

Desde 2011 a filosofia da compilação de pacotes diz que devemos compilá-los baseados na versão mais antiga suportada de cada branch. Por exemplo: se no RELENG-8 as seguintes versões são suportadas: 8.1, 8.2, 8.3; então o packages-8-stable deve ser compilado a partir da versão 8.1.

Quando uma versão chega ao fim de sua vida (End-Of-Life, veja o quadro), uma compilação completa (não incremental!) dos pacotes deve ser realizada e enviada para os servidores de distribuição.

Os procedimentos para o novo código base são os que seguem abaixo:

• Edite o /var/portbuild/conf/server.conf e faça as seguintes mudanças:

  • Altere o SRC_BRANCH_branch_TAG para RELENG_branch_N no qual o N é versão menor mais antiga para este ramo.

• Execute o /var/portbuild/updatesnap manualmente.

• Execute o dopackages com a opção -nobuild.

• Siga os procedimentos de configuração.

• Agora você já pode executar o dopackages sem a opção -nobuild.

O procedimento para o antigo código base fica como um exercício para o leitor.

17 Como configurar uma nova arquitetura

• Crie um novo usuário 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 diretório .ssh.

• Crie um diretório para os logs de compilação e para os logs de erros:

  mkdir /dumpster/pointyhat/arch/archive
  

  Nota: É possível que /dumpster/pointyhat não tenha mais espaço suficiente. Neste caso, crie o diretório dos arquivos como /dumpster/pointyhat/arch/archive e crie um link simbólico para ele. (Isso precisa ser resolvido.)

• Crie um link para o diretório acima para o servidor web:

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

• No diretório /var/portbuild/arch execute:

  mkdir clients
  

• Popule o diretório clients como de costume.

• mkdir loads
  

• mkdir lockfiles
  

• Crie um make.conf local. Nos casos mais comuns você pode executar:

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

• Crie um arquivo vazio mlist.

• (Necessário apenas para o antigo código base) Crie o pnohang.arch. (O modo mais fácil é 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 conveniênte o uso do ssh.

• Crie o diretório de configuração privada:

  mkdir /var/portbuild/conf/arch
  

• Crie os scripts dotunnel.* que forem necessários dentro do diretorio acima.

• Informe o qmanager sobre a arquitetura:

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

• (Necessário apenas para o novo código base): Adicione a arch na variável SUPPORTED_ARCHS do arquivo /var/portbuild/arch/server.conf.

• (Necessário apenas para o antigo código base): Edite o /var/portbuild/scripts/buildenv.

• Adicione o diretório arch no /var/portbuild/scripts/zbackup e no /var/portbuild/scripts/zexpire.

• Necessário apenas para o antigo código base): Como no procedimento para criação de um novo branch: crie os links para o servidor web no diretório /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 simbólicos para o servidor web dentro do diretório /var/portbuild/errorlogs/:

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

• Para cada branch que será suportado, faça o seguinte:

  • Inicie a compilação para o branch com:

    build create arch branch
    

  • Crie o bindist.tar.

• (Necessário apenas para o antigo código base): Só depois que a primeira execução 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 usuário root. (Esta é uma solução paliativa)

18 Como configurar um novo nó principal (instância do pointyhat)

Esta seção está em progresso.

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

19 Procedimentos para lidar com falhas de disco

Quando uma máquina 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 saída 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 forçar a unidade a remapear todos os setores defeituosos que encontrar, isto se ela ainda tiver setores suficientes sobrando. Esta é uma medida temporária para estender o tempo de vida de uma unidade de disco que em breve irá tornar-se inutilizável.

  Nota: Para os sistemas blade i386, outro sinal de falha nos discos é quando a blade fica em espera e não responde a qualquer comando pelo console, ou mesmo pelo NMI.

  Para os outros sistemas de compilação que não executam um newfs nos seus discos no momento da inicialização (por exemplo, os sistemas amd64) este procedimento deve ser ignorado.

• Se o problema persistir, então provavelmente o disco está inutilizado. Remova a máquina 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 também exibirá outros dados, incluindo um log dos erros anteriores da unidade. É possível que a unidade mostre erros de DMA embora não 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 substituí-lo.