3231 lines
114 KiB
XML
3231 lines
114 KiB
XML
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
|
|
<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
|
|
"../../../share/xml/freebsd45.dtd">
|
|
|
|
<!--
|
|
The FreeBSD Documentation Project
|
|
The FreeBSD Brazilian Portuguese Documentation Project
|
|
|
|
Original revision: r39807
|
|
-->
|
|
|
|
<article lang='pt_br'>
|
|
<articleinfo>
|
|
<title>Procedimentos para Construção de Pacotes</title>
|
|
|
|
<authorgroup>
|
|
<corpauthor>Equipe de Gerenciamento da Coleção de Ports do
|
|
&os;</corpauthor>
|
|
</authorgroup>
|
|
|
|
<copyright>
|
|
<year>2003</year>
|
|
<year>2004</year>
|
|
<year>2005</year>
|
|
<year>2006</year>
|
|
<year>2007</year>
|
|
<year>2008</year>
|
|
<year>2009</year>
|
|
<year>2010</year>
|
|
<year>2011</year>
|
|
<year>2012</year>
|
|
<holder role="mailto:portmgr@FreeBSD.org">Equipe de
|
|
Gerenciamento da Coleção de Ports do &os;</holder>
|
|
</copyright>
|
|
|
|
<legalnotice id="trademarks" role="trademarks">
|
|
&tm-attrib.freebsd;
|
|
&tm-attrib.intel;
|
|
&tm-attrib.sparc;
|
|
&tm-attrib.general;
|
|
</legalnotice>
|
|
|
|
<pubdate>$FreeBSD$</pubdate>
|
|
|
|
<releaseinfo>$FreeBSD$</releaseinfo>
|
|
</articleinfo>
|
|
|
|
<sect1 id="intro">
|
|
<title>Introdução</title>
|
|
|
|
<para>Com o objetivo de disponibilizar binários pré-compilados de
|
|
aplicações de terceiros para o &os;, a Coleção de
|
|
<literal>Ports</literal> é regularmente compilada em um dos
|
|
<quote><literal>Clusters</literal> de Compilação de
|
|
Pacotes</quote>. Atualmente o principal
|
|
<literal>cluster</literal> em uso é o <ulink
|
|
url="http://pointyhat.FreeBSD.org"></ulink>.</para>
|
|
|
|
<para>Este artigo documenta os trabalhos internos do
|
|
<literal>cluster</literal></para>
|
|
|
|
<note>
|
|
<para>Muitos dos detalhes deste artigo serão do interesse apenas
|
|
dos membros da equipe que faz o <ulink
|
|
url="&url.base;/portmgr">Gerenciamento da Coleção de
|
|
<literal>Ports</literal></ulink></para>
|
|
</note>
|
|
|
|
<sect2 id="codebase">
|
|
<title>O código base</title>
|
|
|
|
<para>A maior parte da mágica na compilação de pacotes ocorre sob
|
|
o diretório <filename>/var/portbuild</filename>. A menos que
|
|
seja especificado o contrário, todos os caminhos serão relativos
|
|
à este diretório. O <replaceable>${arch}</replaceable> será usado
|
|
para determinar uma das arquiteturas de pacotes (amd64, &i386;,
|
|
ia64, powerpc, e &sparc64;), e
|
|
<replaceable>${branch}</replaceable> será usado para determinar
|
|
o <literal>branch</literal> (ramo de desenvolvimento) de
|
|
compilação (7, 7-exp, 8, 8-exp, 9, 9-exp, 10, 10-exp).</para>
|
|
|
|
<note>
|
|
<para>Não são mais compilados pacotes para as versões 4, 5 ou 6,
|
|
e para a arquitetura alpha</para>
|
|
</note>
|
|
|
|
<para>Os <literal>scripts</literal> que controlam todo o processo
|
|
estão localizados em <filename
|
|
class="directory">/var/portbuild/scripts/</filename>. Eles são
|
|
cópias obtidas do repositório Subversion <ulink
|
|
url="http://svnweb.freebsd.org/base/projects/portbuild/scripts/">
|
|
<filename
|
|
class="directory">base/projects/portbuild/scripts/</filename></ulink>.</para>
|
|
|
|
<para>Normalmente são feitas compilações incrementais que usam
|
|
pacotes anteriores como dependências; isso toma menos tempo, e
|
|
coloca menos carga nos sites espelho. Normalmente são feitas
|
|
compilações completas apenas quando:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>logo depois de uma nova versão, para o ramo
|
|
<literal>-STABLE</literal></para></listitem>
|
|
|
|
<listitem><para>periodicamente, para testar mudanças realizadas
|
|
no <literal>-CURRENT</literal></para></listitem>
|
|
|
|
<listitem><para>para compilações experimentais</para></listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="codebase-notes">
|
|
<title>Observações sobre o código base</title>
|
|
|
|
<para>Até meados de 2010, os <literal>scripts</literal>
|
|
apontavam especificamente para <hostid>pointyhat</hostid> como
|
|
o nó principal (dispatch). Durante o verão de 2010, mudanças
|
|
significativas foram feitas a fim de aceitar outros
|
|
<literal>hosts</literal> como nós principais. Entre estas
|
|
mudanças estão:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>remoção da <literal>string</literal>
|
|
<literal>pointyhat</literal> embutida no
|
|
código</para></listitem>
|
|
|
|
<listitem><para>fatoração de todas as constantes de configuração
|
|
(que antes estavam espalhadas por todo o código) em
|
|
arquivos de configuração (veja <link
|
|
linkend="new-head-node">abaixo</link>)</para></listitem>
|
|
|
|
<listitem><para>adicionar o <literal>hostname</literal> aos
|
|
diretórios especificados pelo <literal>buildid</literal>
|
|
(isto vai permitir que os diretórios sejam inequívocos
|
|
quando copiados entre máquinas.)</para></listitem>
|
|
|
|
<listitem><para>tornar os <literal>scripts</literal> mais
|
|
robustos em termos de criação de diretórios e
|
|
<literal>links</literal> simbólicos</para></listitem>
|
|
|
|
<listitem><para>se necessário, alterar a forma de execução dos
|
|
<literal>scripts</literal> para tornar os itens acima mais
|
|
fáceis.</para></listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>Este documento foi escrito originalmente antes destas
|
|
mudanças serem feitas. Nas partes em que algo foi modificado,
|
|
como nas invocações de <literal>scripts</literal>, elas estão
|
|
denotadas como <literal>novo código base:</literal> em
|
|
oposição à <literal>antigo código base:</literal>.</para>
|
|
|
|
<note>
|
|
<para>Como em dezembro de 2010, o <hostid>pointyhat</hostid>
|
|
ainda está rodando sobre o antigo código base, até que o
|
|
novo código base seja considerado estável.</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Também durante esse processo, o código base foi migrado
|
|
para o <ulink
|
|
url="http://svnweb.freebsd.org/base/projects/portbuild/scripts/">repositório
|
|
Subversion</ulink>. Para referência, a versão
|
|
anterior ainda pode ser <ulink
|
|
url="http://www.freebsd.org/cgi/cvsweb.cgi/ports/Tools/portbuild/scripts/Attic/">encontrada
|
|
no CVS</ulink>.</para>
|
|
</note>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="management">
|
|
<title>Gerenciamento dos Clientes de Compilação</title>
|
|
|
|
<para>Os clientes &i386; localizados conjuntamente com o
|
|
<hostid>pointyhat</hostid>, efetuam o <literal>boot</literal>
|
|
via rede a partir dele (nós
|
|
<replaceable>conectados</replaceable>); todos os outros clientes
|
|
(nós <replaceable>desconectados</replaceable>) ou são
|
|
auto-hospedados ou efetuam <literal>boot</literal> via rede a
|
|
partir de outro <literal>host pxe</literal>. Em todos os casos
|
|
eles se auto configuram durante o <literal>boot</literal>
|
|
preparando-se para compilar pacotes.</para>
|
|
|
|
<para>O <literal>cluster</literal> principal copia, através do
|
|
<command>rsync</command>, os dados necessários (a árvore de
|
|
<literal>ports</literal> e dos fontes, <literal>bindist
|
|
tarballs</literal>, <literal>scripts</literal>, etc.) para os
|
|
nós desconectados durante a fase de configuração dos nós. Em
|
|
seguida, o diretório <literal>portbuild</literal> desconectado é
|
|
montado como <literal>nullfs</literal> para compilações sob
|
|
<literal>chroot</literal>.</para>
|
|
|
|
<para>O usuário
|
|
<username>ports-<replaceable>${arch}</replaceable></username>
|
|
pode acessar os nós clientes através do &man.ssh.1; para
|
|
monitorá-los. Use o <command>sudo</command> e verifique o
|
|
<hostid>portbuild.<replaceable>hostname</replaceable>.conf</hostid>
|
|
para o usuário e detalhes do acesso.</para>
|
|
|
|
<para>O <literal>script</literal>
|
|
<command>scripts/allgohans</command> pode ser usado para
|
|
executar um comando em todos os clientes
|
|
<replaceable>${arch}</replaceable>.</para>
|
|
|
|
<para>O <literal>script</literal>
|
|
<command>scripts/checkmachines</command> é usado para monitorar
|
|
a carga em todos os nós do <literal>cluster</literal> de
|
|
compilação, e agendar quais nós compilarão quais
|
|
<literal>ports</literal>. Este <literal>script</literal> não é
|
|
muito robusto e tem uma tendência a morrer. É melhor iniciar
|
|
este <literal>script</literal> no nó principal (por exemplo,
|
|
<hostid>pointyhat</hostid>) depois do <literal>boot</literal>
|
|
usando um <literal>loop</literal> com &man.while.1;.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="setup">
|
|
<title>Configuração do Ambiente de Compilação sob
|
|
<literal>Chroot</literal></title>
|
|
|
|
<para>A compilação de pacotes é realizada em um ambiente
|
|
<literal>chroot</literal>, configurado pelo
|
|
<literal>script</literal> <filename>portbuild</filename> usando
|
|
o arquivo
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/bindist.tar</filename>.
|
|
</para>
|
|
|
|
<para>O seguinte comando faz o <literal>build world</literal>
|
|
a partir da árvore de diretórios em
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/src/</filename>
|
|
e o instala em <replaceable>${worlddir}</replaceable>. A
|
|
árvore de diretórios será atualizada primeiro, a menos que a
|
|
opção <literal>-nocvs</literal> seja especificada.</para>
|
|
|
|
<screen>/var/portbuild&prompt.root; <userinput>scripts/makeworld <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> [-nocvs]</userinput></screen>
|
|
|
|
<para>O arquivo <filename>bindist.tar</filename> é criado a partir
|
|
do <literal>world</literal>, instalado previamente, pelo
|
|
<literal>script</literal> <command>mkbindist</command>. Este
|
|
deve ser executado como <username>root</username> com o
|
|
seguinte comando:</para>
|
|
|
|
<screen>/var/portbuild&prompt.root; <userinput>scripts/mkbindist <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable></userinput></screen>
|
|
|
|
<para>Os <literal>tarballs</literal> de cada máquina estão
|
|
localizados em
|
|
<filename><replaceable>${arch}</replaceable>/clients</filename>.</para>
|
|
|
|
<para>O arquivo <filename>bindist.tar</filename> é extraído para
|
|
cada cliente durante a inicialização dos mesmos, e no início de
|
|
cada passagem do <literal>script</literal>
|
|
<command>dopackages</command>.</para>
|
|
|
|
<sect2>
|
|
<title>Novo Código Base</title>
|
|
|
|
<para>Para ambos os comandos acima, se o
|
|
<replaceable>${buildid}</replaceable> estiver definido como
|
|
<literal>latest</literal>, ele pode ser omitido.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="customizing">
|
|
<title>Customizando Sua Compilação</title>
|
|
|
|
<para>(O trecho a seguir aplica-se apenas ao novo código
|
|
base.)</para>
|
|
|
|
<para>Você pode customizar sua compilação providenciando versões
|
|
locais do <filename>make.conf</filename> e/ou
|
|
<filename>src.conf</filename>, localizados em
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/make.conf.server</filename>
|
|
e
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/src.conf.server</filename>,
|
|
respectivamente. Estes serão usados, em vez dos arquivos
|
|
padrões que estão no lado do servidor.</para>
|
|
|
|
<para>Da mesma forma, se você também quiser afetar o
|
|
<filename>make.conf</filename> no <emphasis>lado do
|
|
cliente</emphasis>, você pode usar o
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/make.conf.client</filename>.
|
|
</para>
|
|
|
|
<note>
|
|
<para>Devido ao fato de cada um dos clientes individuais poder
|
|
ter seu próprio <filename>make.conf</filename>, o conteúdo do
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/make.conf.client</filename>
|
|
vai ser <emphasis>adicionado</emphasis> ao
|
|
<filename>make.conf</filename>, e não substituí-lo, como é feito
|
|
com o
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/make.conf.server</filename>.
|
|
</para>
|
|
</note>
|
|
|
|
<note>
|
|
<para>Não existe nenhuma funcionalidade semelhante para
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable>/src.conf.client</filename>
|
|
(e que efeito teria?).</para>
|
|
</note>
|
|
|
|
<example>
|
|
<title>Exemplo de
|
|
<filename>make.conf.<replaceable>target</replaceable></filename>
|
|
para testar a nova versão padrão do
|
|
<application>ruby</application></title>
|
|
|
|
<para>(Neste caso, os conteúdos são idênticos para ambos,
|
|
servidor e cliente.)</para>
|
|
|
|
<screen>RUBY_DEFAULT_VER= 1.9</screen>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Exemplo de
|
|
<filename>make.conf.<replaceable>target</replaceable></filename>
|
|
para compilação do <application>clang</application></title>
|
|
|
|
<para>(Neste caso, os conteúdos também são idênticos para ambos,
|
|
servidor e cliente.)</para>
|
|
|
|
<screen>
|
|
.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=
|
|
</screen>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Exemplo de <filename>make.conf.server</filename> para
|
|
<application>pkgng</application></title>
|
|
|
|
<screen>WITH_PKGNG=yes
|
|
PKG_BIN=/usr/local/sbin/pkg</screen>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Exemplo de <filename>make.conf.client</filename> para
|
|
<application>pkgng</application></title>
|
|
|
|
<screen>WITH_PKGNG=yes</screen>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Exemplo de <filename>src.conf.server</filename> para
|
|
testar uma versão nova do código base do
|
|
<application>sort</application></title>
|
|
|
|
<screen>WITH_BSD_SORT=yes</screen>
|
|
</example>
|
|
</sect1>
|
|
|
|
<sect1 id="starting">
|
|
<title>Iniciando a Compilação</title>
|
|
|
|
<para>Várias compilações separadas para cada arquitetura - a
|
|
combinação de <literal>branchs</literal> é suportada. Todos os
|
|
dados privados para uma compilação (árvore de
|
|
<literal>ports</literal>, árvore do <literal>src</literal>,
|
|
pacotes, <literal>distfiles</literal>, arquivos de
|
|
<literal>log</literal>, <literal>bindist</literal>,
|
|
<literal>Makefile</literal>, etc) estão localizados sob
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/builds/<replaceable>${buildid}</replaceable></filename>.
|
|
Alternativamente, a última compilação pode ser referenciada sob
|
|
o <literal>buildid</literal> <literal>latest</literal>, e a
|
|
anterior a esta é chamada <literal>previous</literal>.</para>
|
|
|
|
<para>Novas compilações são clonadas a partir da
|
|
<literal>latest</literal>, o que é rápido, uma vez que ele usa
|
|
ZFS.</para>
|
|
|
|
<sect2 id="build-dopackages">
|
|
<title>Os <literal>Scripts</literal>
|
|
<command>dopackages</command></title>
|
|
|
|
<para>Os <literal>scripts</literal>
|
|
<filename>scripts/dopackages</filename> são usados para executar
|
|
as compilações.</para>
|
|
|
|
<sect3>
|
|
<title>Código base antigo</title>
|
|
<para>Para o código base antigo, os mais úteis são:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><command>dopackages.7</command> - Executa a compilação
|
|
para a série 7.X
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.7-exp</command> - Executa a
|
|
compilação para a série 7.X com <literal>patches</literal>
|
|
experimentais (<literal>branch</literal> 7-exp)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.8</command> - Executa a
|
|
compilação para a série 8.X.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.8-exp</command> - Executa a
|
|
compilação para a série 8.X com <literal>patches</literal>
|
|
experimentais (<literal>branch</literal> 8-exp)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.9</command> - Executa a
|
|
compilação para a série 9.X.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.9-exp</command> - Executa a
|
|
compilação para a série 9.X com <literal>patches</literal>
|
|
experimentais (<literal>branch</literal> 9-exp)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.10</command> - Executa a
|
|
compilação para a série 10.X.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><command>dopackages.10-exp</command> - Executa a
|
|
compilação para a série 10.X com <literal>patches</literal>
|
|
experimentais (<literal>branch</literal> 10-exp)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Esses são <literal>wrappers</literal> para o
|
|
<command>dopackages</command> e todos são
|
|
<literal>links</literal> simbólicos para
|
|
<command>dopackages.wrapper</command>.
|
|
<literal>Wrappers</literal> de <literal>scripts</literal> para
|
|
um novo <literal>branch</literal> podem ser criados com
|
|
<literal>links</literal> simbólicos
|
|
<command>dopackages.${branch}</command> para
|
|
<command>dopackages.wrapper</command>. Esses
|
|
<literal>scripts</literal> tem uma série de argumentos. Por
|
|
exemplo:</para>
|
|
|
|
<screen><command>dopackages.7 <replaceable>${arch}</replaceable> <replaceable>${buildid}</replaceable> <literal>[-options]</literal></command></screen>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Novo código base</title>
|
|
|
|
<para>Você pode usar o <command>dopackages.wrapper</command>
|
|
diretamente, ao invés dos <literal>links</literal> simbólicos.
|
|
Por exemplo:</para>
|
|
|
|
<screen><command>dopackages.wrapper <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> <literal>[-options]</literal></command></screen>
|
|
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Para ambos os códigos base</title>
|
|
|
|
<para>Frequentemente você usará <literal>latest</literal> como
|
|
valor para o <replaceable>buildid</replaceable>.</para>
|
|
|
|
<para><literal>[-options]</literal> pode ser nulo, uma ou mais,
|
|
das opções seguintes:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>-keep</literal> - Não remove esta compilação no
|
|
futuro, quando normalmente seria removido como parte do
|
|
ciclo <literal>latest</literal> -
|
|
<literal>previous</literal>. Não se esqueça de efetuar a
|
|
limpeza manualmente quando ele não for mais
|
|
necessário.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-nofinish</literal> - Não executa o
|
|
pós-processamento após finalizar a compilação.
|
|
Isto é útil se você espera que a compilação precise ser
|
|
reiniciada depois de concluída. Se você usar esta opção,
|
|
não se esqueça de limpar os clientes quando você não
|
|
precisar mais da compilação.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-finish</literal> - Executa apenas o
|
|
pós-processamento.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-nocleanup</literal> - Por padrão, quando o
|
|
estágio <literal>-finish</literal> da compilação é
|
|
completado, os dados da compilação serão removidos dos
|
|
clientes. Esta opção vai evitar a remoção dos
|
|
dados.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-restart</literal> - Reinicia uma compilação
|
|
interrompida (ou não finalizada) a partir do começo. Os
|
|
<literal>Ports</literal> que falharam na compilação
|
|
anterior serão recompilados.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-continue</literal> - Reinicia uma compilação
|
|
interrompida (ou não finalizada). Os
|
|
<literal>Ports</literal> que falharam na compilação anterior
|
|
não serão recompilados.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-incremental</literal> - Compara os campos
|
|
importantes do novo <literal>INDEX</literal> com a versão
|
|
anterior, remove pacotes e arquivos de
|
|
<literal>log</literal> dos <literal>ports</literal> antigos
|
|
que foram alterados, e recompila o resto. Isso reduz o
|
|
tempo de compilação substancialmente, pois os
|
|
<literal>ports</literal> inalterados não serão recompilados
|
|
todas as vezes.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-cdrom</literal> - O empacotamento desta
|
|
compilação será usado em um CD-ROM, então os pacotes
|
|
marcados como <literal>NO_CDROM</literal> e os
|
|
<literal>disfiles</literal> deverão ser removidos no
|
|
pós-processamento.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-nobuild</literal> - executa todas as etapas do
|
|
pré-processamento, mas não a compilação dos pacotes.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-noindex</literal> - Não reconstrói o
|
|
<filename>INDEX</filename> durante o pré-processamento.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-noduds</literal> - Não reconstrói o arquivo
|
|
<filename>duds</filename> (<literal>ports</literal> que
|
|
nunca são compilados, como por exemplo, aqueles marcados com
|
|
<literal>IGNORE</literal>, <literal>NO_PACKAGE</literal>,
|
|
etc.) durante o pré-processamento.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-nochecksubdirs</literal> - Não verifica o
|
|
<makevar>SUBDIRS</makevar> para os <literal>ports</literal>
|
|
que não estão ligados à compilação. (Apenas para o novo
|
|
código base).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-trybroken</literal> - Tenta compilar
|
|
<literal>ports</literal> marcados como
|
|
<literal>BROKEN</literal> (desativado por padrão, pois os
|
|
<literal>clusters</literal> amd64/&i386; agora são
|
|
suficientemente rápidos e quando fazem compilações
|
|
incrementais eles gastam muito mais tempo do que o
|
|
necessário para compilar tudo. Por outro lado,
|
|
os outros <literal>clusters</literal> são bastante lentos,
|
|
e seria um desperdício de tempo tentar compilar
|
|
<literal>ports</literal> marcados como
|
|
<literal>BROKEN</literal>).
|
|
</para>
|
|
<note>
|
|
<para>Com <literal>-trybroken</literal>, provavelmente você
|
|
também vai querer usar <literal>-fetch-original</literal>
|
|
(e, no novo código base,
|
|
<literal>-unlimited-errors</literal>).</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-nosrc</literal> - Não atualiza a árvore do
|
|
<literal>src</literal> a partir do
|
|
<literal>snapshot</literal> do ZFS, mantendo a árvore da
|
|
compilação anterior.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-srccvs</literal> - Não atualiza a árvore do
|
|
<literal>src</literal> a partir do
|
|
<literal>snapshot</literal> do ZFS, em vez disso ela é
|
|
atualizada com o <literal>cvs update</literal>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-noports</literal> - Não atualiza a árvore de
|
|
<literal>ports</literal> a partir do
|
|
<literal>snapshot</literal> do ZFS, mantendo a árvore da
|
|
compilação anterior.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-portscvs</literal> - Não atualiza a árvore de
|
|
<literal>ports</literal> a partir do
|
|
<literal>snapshot</literal> do ZFS, em vez disso ela é
|
|
atualizada com o <literal>cvs update</literal>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-norestr</literal> - Não tenta compilar
|
|
<literal>ports</literal> marcados como
|
|
<literal>RESTRICTED</literal>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-noplistcheck</literal> - Não considera como
|
|
erro <literal>ports</literal> deixarem arquivos para trás
|
|
ao serem removidos.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-nodistfiles</literal> - Não coleta os
|
|
<literal>distfiles</literal> que passarem no <command>make
|
|
checksum</command> para depois fazer o
|
|
<foreignphrase>upload</foreignphrase> para o
|
|
<hostid>ftp-master</hostid>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-fetch-original</literal> - Baixa o
|
|
<literal>distfile</literal> a partir do
|
|
<literal>MASTER_SITES</literal> original, em vez do
|
|
<hostid>ftp-master</hostid>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>-unlimited-errors</literal> (apenas no novo
|
|
código base) - anula a verificação de limites do qmanager
|
|
para compilações descontroladas. Você pode querer isso
|
|
principalmente quando usar <literal>-restart</literal> em
|
|
uma compilação que provavelmente vai falhar, ou talvez
|
|
quando executar <literal>-trybroken</literal>. A
|
|
A limitação é realizada por padrão.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>A menos que você especifique <literal>-restart</literal>,
|
|
<literal>-continue</literal>, ou <literal>-finish</literal>, os
|
|
<literal>links</literal> simbólicos para as compilações
|
|
existentes serão rotacionados. Isto é, o
|
|
<literal>link</literal> simbólico para
|
|
<filename>previous</filename> será removido; a compilação mais
|
|
recente terá seu <literal>link</literal> modificado para
|
|
<filename>previous/</filename>; e a nova compilação será criada
|
|
e referenciada com um <literal>link</literal> em
|
|
<filename>latest/</filename>.
|
|
</para>
|
|
|
|
<para>Se a última compilação finalizou de forma limpa, você
|
|
não precisa remover nada. Se ela foi interrompida, ou você usou
|
|
a opção <literal>-nocleanup</literal>, você precisa limpar os
|
|
clientes executando:
|
|
</para>
|
|
|
|
<para><command>build cleanup <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> -full</command></para>
|
|
|
|
<para>Os diretórios <filename>errors/</filename>,
|
|
<filename>logs/</filename>, <filename>packages/</filename>, e
|
|
assim por diante, são limpos pelos <literal>scripts</literal>.
|
|
Se você está com pouco espaço, também pode limpar o
|
|
<filename>ports/distfiles/</filename>. Não altere o diretório
|
|
<filename>latest/</filename>; ele é um link simbólico para o
|
|
servidor web.</para>
|
|
|
|
<note>
|
|
<para>O <literal>dosetupnodes</literal> supostamente é executado
|
|
pelo <literal>script</literal> <literal>dopackages</literal>
|
|
no caso de <literal>-restart</literal>, mas pode ser uma boa
|
|
idéia executá-lo manualmente e depois verificar se todos os
|
|
clientes tem a carga de trabalho esperada. Algumas vezes
|
|
<literal>dosetupnode</literal> não pode limpar uma compilação
|
|
e você precisará fazer isso manualmente. (Isto é um
|
|
defeito.)</para>
|
|
</note>
|
|
|
|
<para>Verifique se a compilação de pacotes para a arquitetura
|
|
<replaceable>${arch}</replaceable> está executando como
|
|
usuário ports-<replaceable>${arch}</replaceable> ou ele
|
|
apresentará um grande número de erros.</para>
|
|
|
|
<note><para>Atualmente, a própria compilação de pacotes ocorre em
|
|
duas fases idênticas. A razão para isso é que, algumas vezes,
|
|
problemas temporários (por exemplo, falhas do NFS, sites FTP
|
|
inalcançáveis, etc.) podem quebrar a compilação. Realizar o
|
|
processo em duas fases é uma solução alternativa para esse tipo
|
|
de problema.</para></note>
|
|
|
|
<para>Seja cuidadoso com <filename>ports/Makefile</filename> para
|
|
não especificar qualquer diretório vazio. Isso é especialmente
|
|
importante se você está realizando uma compilação com
|
|
<literal>patches</literal> experimentais (-exp). Se o processo
|
|
de compilação encontrar um diretório vazio, ambas as fases de
|
|
compilação irão parar rapidamente, e um erro similar ao seguinte
|
|
será adicionado para
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/make.[0|1]</filename>:
|
|
</para>
|
|
|
|
<screen><literal>don't know how to make dns-all(continuing)</literal></screen>
|
|
|
|
<para>Para corrigir este problema, simplesmente comente ou remova
|
|
as entradas <literal>SUBDIR</literal> que apontam para
|
|
subdiretórios vazios. Depois de feito isso, você pode
|
|
reiniciar a compilação executando o comando
|
|
<command>dopackages</command> adequado com a opção
|
|
<literal>-restart</literal>.
|
|
</para>
|
|
|
|
<note>
|
|
<para>Este problema também ocorre se você criar uma nova
|
|
categoria com um <filename>Makefile</filename> sem entradas
|
|
<makevar>SUBDIR</makevar>s nele. Isso é, provavelmente, um
|
|
defeito.</para>
|
|
</note>
|
|
|
|
<example>
|
|
<title>Atualize a árvore i386-7 e faça uma compilação
|
|
completa</title>
|
|
|
|
<para><command>dopackages.7 i386 -nosrc -norestr -nofinish</command></para>
|
|
<para><command>dopackages.wrapper i386 7 -nosrc -norestr -nofinish</command></para>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Reinicie uma compilação para amd64-8 interrompida sem
|
|
atualizar</title>
|
|
|
|
<para><command>dopackages.8 amd64 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</command></para>
|
|
<para><command>dopackages.wrapper amd64 8 -nosrc -noports -norestr -continue -noindex -noduds -nofinish</command></para>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Realize o pós-processamento de uma árvore sparc64-7
|
|
concluída</title>
|
|
|
|
<para><command>dopackages.7 sparc64 -finish</command></para>
|
|
<para><command>dopackages.wrapper sparc64 7 -finish</command></para>
|
|
</example>
|
|
|
|
<para>Dica: geralmente é melhor executar o comando
|
|
<command>dopackages</command> dentro do
|
|
<command>screen(1)</command>.</para>
|
|
</sect3>
|
|
</sect2>
|
|
|
|
<sect2 id="build-command">
|
|
<title>O comando <command>build</command></title>
|
|
|
|
<para>Você pode precisar manipular os dados da compilação antes
|
|
de inicia-la, especialmente para compilações experimentais.
|
|
Isto é feito com o comando <command>build</command>. Aqui
|
|
estão algumas opções úteis para criação:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>build create <replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable>
|
|
[<replaceable>newid</replaceable>]</literal> - Cria um
|
|
<replaceable>newid</replaceable> (ou um
|
|
<literal>datestamp</literal>, se não for especificado).
|
|
Só é necessário quando da criação de um novo
|
|
<literal>branch</literal> ou uma nova arquitetura. (TODO:
|
|
documentar se <literal>newid</literal> deve ser
|
|
especificado como <literal>latest</literal> no novo código
|
|
base.)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>build clone <replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable>
|
|
<replaceable>oldid</replaceable>
|
|
[<replaceable>newid</replaceable>]</literal> - Cria um
|
|
clone do <replaceable>oldid</replaceable> para o
|
|
<replaceable>newid</replaceable> (ou um
|
|
<literal>datestamp</literal>, se não for especificado).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>build srcupdate
|
|
<replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable>
|
|
<replaceable>buildid</replaceable></literal> - Substitui
|
|
a árvore <literal>src</literal> com um novo
|
|
<literal>snapshot</literal> do ZFS. Não se esqueça de
|
|
usar a opção <literal>-nosrc</literal> quando executar o
|
|
<command>dopackages</command> mais tarde!
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>build portsupdate
|
|
<replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable>
|
|
<replaceable>buildid</replaceable></literal> - Substitui a
|
|
árvore de <literal>ports</literal> com um novo
|
|
<literal>snapshot</literal> do ZFS. Não se esqueça de
|
|
usar a opção <literal>-noports</literal> quando executar
|
|
<command>dopackages</command> mais tarde!
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2 id="build-one">
|
|
<title>Compilando um único pacote</title>
|
|
|
|
<para>Algumas vezes é necessário recompilar um único pacote a
|
|
partir do conjunto de pacotes. Isso pode ser feito executando
|
|
o seguinte comando:</para>
|
|
|
|
<para><command><replaceable>path</replaceable>/qmanager/packagebuild <replaceable>amd64</replaceable> <replaceable>7-exp</replaceable> <replaceable>20080904212103</replaceable> <replaceable>aclock-0.2.3_2.tbz</replaceable></command></para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="anatomy">
|
|
<title>Anatomia de uma compilação</title>
|
|
|
|
<para>Uma compilação completa, sem qualquer opção
|
|
<literal>-no</literal> que desabilite as opções padrões, executa
|
|
as seguintes operações na ordem especificada:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Atualiza a árvore de <literal>ports</literal> atual a
|
|
partir de um <literal>snapshot</literal> do ZFS [*]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Atualiza o <literal>branch</literal> usado na árvore
|
|
<literal>src</literal> a partir de um
|
|
<literal>snapshot</literal> do ZFS [*]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Verifica se <literal>ports</literal> não têm uma
|
|
entrada <literal>SUBDIR</literal> no
|
|
<filename>Makefile</filename> de suas respectivas categorias
|
|
[*]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Cria o arquivo <filename>duds</filename>, que é uma
|
|
lista de <literal>ports</literal> que não precisam ser
|
|
compilados [*] [+]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Cria um arquivo <filename>INDEX</filename> atualizado
|
|
[*] [+]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Define os nós que serão usados na compilação [*] [+]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Compila uma lista de <literal>ports</literal> restritos
|
|
[*] [+]</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Compila os pacotes (fase 1) [++]</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Executa outra configuração do nó [+]</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Compila os pacotes (fase 2) [++]</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>[*] O status destes passos pode ser encontrado em
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/build.log</filename>,
|
|
bem como no <literal>stderr</literal> do <literal>tty</literal>
|
|
onde o comando <command>dopackages</command> está
|
|
rodando.</para>
|
|
|
|
<para>[+] Se qualquer destes passos falhar, a compilação será
|
|
encerrada.</para>
|
|
|
|
<para>[++] O status destes passos pode ser encontrado em
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/make</filename>
|
|
(antigo código base) ou
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/journal</filename>
|
|
(novo código base). <literal>Ports</literal> individuais irão
|
|
escrever seus <literal>logs</literal> de compilação em
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/logs</filename>
|
|
e os seus <literal>logs</literal> de erros em
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/errors</filename>.
|
|
</para>
|
|
|
|
<para>Anteriormente, a árvore <literal>docs</literal> também era
|
|
verificada, no entanto, isso se mostrou desnecessário.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="build-maintenance">
|
|
<title>Manutenção da Compilação</title>
|
|
|
|
<para>Existem vários casos onde você precisará limpar manualmente
|
|
uma compilação:
|
|
</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>Você a interrompeu manualmente.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>O <hostid>pointyhat</hostid> foi reiniciado enquanto uma
|
|
compilação estava executando.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>O <filename>qmanager</filename> falhou e reiniciado</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<sect2 id="interrupting">
|
|
<title>Interrompendo uma Compilação</title>
|
|
|
|
<para>O processo para interromper de forma manual uma compilação
|
|
é um tanto quanto confuso. Primeiro você precisa identificar o
|
|
<literal>tty</literal> em que ela está sendo executada rodando
|
|
(ou lembrando-se da saída do &man.tty.1;
|
|
quando você iniciou a compilação, ou usando <command>ps
|
|
x</command> para identificá-lo). Você precisa certificar-se de
|
|
que não existe mais nada importante rodando neste
|
|
<literal>tty</literal>, você pode verificar isto executando o
|
|
comando <command>ps</command>, por exemplo,
|
|
<command>ps -t p1</command> lista os processos em execução
|
|
no tty 1. Se não existir mais nada importante, você pode
|
|
encerrar o terminal facilmente com
|
|
<command>pkill -t pts/1</command>; ou pode utilizar o
|
|
<command>kill -HUP</command>, por exemplo,
|
|
<command>ps -t pts/1 -o pid= | xargs kill -HUP</command>.
|
|
Você deve Substitur o <replaceable>p1</replaceable> pelo
|
|
<literal>tty</literal> utilizado na compilação.</para>
|
|
|
|
<para>A compilação de pacote enviada pelo <command>make</command>
|
|
para as máquinas clientes irá se auto limpar após alguns minutos
|
|
(verifique com <command>ps x</command> até que todos
|
|
finalizem).</para>
|
|
|
|
<para>Se você não encerrar o &man.make.1;, ele irá iniciar novas
|
|
tarefas de compilação. Se você não encerrar o
|
|
<command>dopackages</command> ele irá reiniciar toda a
|
|
compilação. Se você não encerrar
|
|
os processos <command>pdispatch</command>, eles irão continuar
|
|
(ou reaparecer) até concluir a compilação do pacote.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="cleanup">
|
|
<title>Limpando uma Compilação</title>
|
|
|
|
<para>Para liberar recursos, você precisa limpar as máquinas
|
|
clientes executando o comando <command>build cleanup</command>.
|
|
Por exemplo:</para>
|
|
|
|
<screen>&prompt.user; <userinput>/var/portbuild/scripts/build cleanup i386 8-exp 20080714120411 -full</userinput></screen>
|
|
|
|
<para>Se você esquecer de fazer isso, então os
|
|
<literal>chroot</literal>s da compilação antiga não serão limpos
|
|
nas próximas 24 horas, e nenhum novo trabalho será iniciado no
|
|
seu lugar enquanto o <hostid>pointyhat</hostid> achar que esta
|
|
máquina ainda está ocupada.</para>
|
|
|
|
<para>Para verificar, utilize o comando
|
|
<command>cat ~/loads/*</command> para
|
|
mostrar o status das máquinas clientes; a primeira coluna é o
|
|
número de trabalhos que ela pensa estar executando, e isso pode
|
|
estar bem próximo da carga média. O <literal>loads</literal> é
|
|
atualizado a cada 2 minutos. Se você executar um
|
|
<command>ps x | grep pdispatch</command> e ele listar menos
|
|
trabalhos do que os que o <literal>loads</literal> pensa estarem
|
|
em uso, você está em apuros.</para>
|
|
|
|
<para>Você pode ter problemas com instâncias do comando
|
|
<command>umount</command> ficando congeladas. Se isto ocorrer,
|
|
você terá que usar o <literal>script</literal>
|
|
<command>allgohans</command> para executar um comando
|
|
&man.ssh.1; em todos os clientes deste ambiente de compilação.
|
|
Por exemplo:</para>
|
|
|
|
<screen>ssh -l root gohan24 df</screen>
|
|
|
|
<para>Vai lhe dar um <command>df</command>, e</para>
|
|
|
|
<screen>allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/ports"
|
|
allgohans "umount -f pointyhat.freebsd.org:/var/portbuild/i386/8-exp/src"</screen>
|
|
|
|
<para>Supostamente irá resolver o problema dos
|
|
<literal>mounts</literal> que não foram desconectados pelo
|
|
<command>umount</command>. Você terá que continuar
|
|
executando-os pois podem existir diversas
|
|
montagens.</para>
|
|
|
|
<note>
|
|
<para>Ignore o seguinte:</para>
|
|
|
|
<screen>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</screen>
|
|
|
|
<para>Os dois primeiros significam que o cliente não tinha o
|
|
sistema de arquivos montado; os dois últimos são um
|
|
defeito.</para>
|
|
|
|
<para>Você também poderá ver mensagens sobre o
|
|
<literal>procfs</literal>.</para>
|
|
</note>
|
|
|
|
<para>Após concluir tudo que foi exposto acima, remova o arquivo
|
|
<filename><replaceable>${arch}</replaceable>/lock</filename>
|
|
antes de tentar reiniciar a compilação. Se você não o fizer,
|
|
o <filename>dopackages</filename> simplesmente será encerrado.
|
|
</para>
|
|
|
|
<para>Se você atualizou a árvore de <literal>ports</literal> antes
|
|
de reiniciar, você pode precisar reconstruir o
|
|
<filename>duds</filename>, o <filename>INDEX</filename>, ou
|
|
ambos os arquivos.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="build-command-2">
|
|
<title>Manutenção de compilações com o comando
|
|
<command>build</command></title>
|
|
|
|
<para>Aqui está o resto das opções para o comando
|
|
<command>build</command>:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>build destroy <replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable></literal> - Destrói o
|
|
<literal>id</literal> da compilação.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>build list <replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable></literal> - Mostra o
|
|
conjunto atual de <literal>ids</literal> de compilações.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>build upload <replaceable>arch</replaceable>
|
|
<replaceable>branch</replaceable></literal> - ainda não
|
|
implementado.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="monitoring">
|
|
<title>Monitorando a Compilação</title>
|
|
|
|
<para>Você pode usar o comando <command>qclient</command> para
|
|
monitorar o status dos nós de compilação, e para listar as
|
|
tarefas de compilação agendadas para execução:</para>
|
|
|
|
<para><command>python <replaceable>path</replaceable>/qmanager/qclient jobs</command></para>
|
|
<para><command>python <replaceable>path</replaceable>/qmanager/qclient status</command></para>
|
|
|
|
<para>O comando
|
|
<command>scripts/stats <replaceable>${branch}</replaceable></command>
|
|
mostra o número de pacotes cuja compilação já finalizou.</para>
|
|
|
|
<para>A execução de um
|
|
<command>cat /var/portbuild/*/loads/*</command>
|
|
irá mostrar o <literal>load</literal> 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
|
|
<literal>online</literal>; os demais arquivos são dos clientes
|
|
que estão <literal>offline.</literal></para>
|
|
|
|
<note>
|
|
<para>O comando <command>pdispatch</command> faz o envio de
|
|
trabalhos para o cliente, e executa tarefas de
|
|
pós-processamento a partir do retorno recebido do client. O
|
|
<command>ptimeout.host</command> monitora permanentemente o
|
|
processo de compilação e a encerra após a ocorrência de
|
|
<literal>timeouts</literal>. Desta forma, se você tiver
|
|
50 processos <command>pdispatch</command>, mas apenas 4
|
|
processos &man.ssh.1;, significa que 46 processos
|
|
<command>pdispatch</command>es estão ociosos, esperando que
|
|
um nó fique livre.</para>
|
|
</note>
|
|
|
|
<para>Executar <command>tail -f <replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/build.log</command>
|
|
irá mostrar o progresso geral da compilação.</para>
|
|
|
|
<para>Se a compilação do <literal>port</literal> falhar, e o
|
|
motivo não ficar imediatamente óbvio a partir da análise do
|
|
<literal>log</literal>, você pode preservar o
|
|
<literal>WRKDIR</literal> para uma análise mais aprofundada.
|
|
Para fazer isso, crie um arquivo vazio chamado
|
|
<filename>.keep</filename> no diretório do
|
|
<literal>port</literal>, isso vai arquivar,
|
|
comprimir, e copiar o <literal>WRKDIR</literal> para
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/wrkdirs</filename>.
|
|
</para>
|
|
|
|
<para>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.</para>
|
|
|
|
<para>Se todas as compilações iniciam reclamando de que não pode
|
|
carregar os pacotes dos quais ela depende, verifique se o
|
|
<application>httpd</application> ainda está rodando, e o i
|
|
reinicie se não estiver.</para>
|
|
|
|
<para>Mantenha o olho na saída do &man.df.1;. Se o sistema de
|
|
arquivos do <filename>/var/portbuild</filename> ficar cheio,
|
|
coisas ruins acontecem.</para>
|
|
|
|
<para>O status de todas as compilações é gerado duas vezes por
|
|
hora e postado em <ulink
|
|
url="http://pointyhat.FreeBSD.org/errorlogs/packagestats.html"></ulink>.
|
|
Para cada <literal>buildenv</literal> é apresentado o
|
|
seguinte:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>cvs date</literal> é o conteúdo do
|
|
<filename>cvsdone</filename>. É por isso que nós
|
|
recomendamos que você atualize o
|
|
<filename>cvsdone</filename> para executar compilações
|
|
experimentais, <literal>-exp</literal> (veja abaixo).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>data do último <literal>log</literal>
|
|
(<literal>latest log</literal>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>número de linhas no <literal>INDEX</literal></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>o número atual de <literal>logs</literal> de
|
|
compilações (<literal>build logs</literal>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>o número de pacotes concluídos
|
|
(<literal>packages</literal>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>o número de erros (<literal>errors</literal>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>o número de <literal>ports</literal> ignorados (duds)
|
|
(listados como <literal>skipped</literal>)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A coluna <literal>missing</literal> mostra a diferença
|
|
entre o <filename>INDEX</filename> e as outras colunas.
|
|
Se você reiniciou uma compilação após um <command>cvs
|
|
update</command>, provavelmente haverá duplicatas nos
|
|
pacotes e colunas de erros, e esta coluna será inútil. (O
|
|
<literal>script</literal> é ingênuo).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Os valores das colunas <literal>running</literal> e
|
|
<literal>completed</literal> são palpites baseados em um
|
|
&man.grep.1; do <filename>build.log</filename>.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="errors">
|
|
<title>Lidando com Erros de Compilação</title>
|
|
|
|
<para>A maneira mais fácil de rastrear falhas na compilação é
|
|
receber os <literal>logs</literal> 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
|
|
<filename><replaceable>${branch}</replaceable>/portbuild.conf</filename>.
|
|
Você pode encaminhar facilmente os novos erros para os
|
|
mantenedores.</para>
|
|
|
|
<para>Quando um <literal>port</literal> passa a não compilar
|
|
corretamente durante varios ciclos de compilação seguidos,
|
|
é hora de marcá-lo como quebrado (<literal>BROKEN</literal>).
|
|
Recomenda-se notificar os mantenedores durante duas semanas,
|
|
antes de fazê-lo.</para>
|
|
|
|
<note>
|
|
<para>Para evitar erros de compilação dos
|
|
<literal>ports</literal> cujo código fonte precisa ser
|
|
baixado manualmente, coloque os <literal>distfiles</literal>
|
|
em <filename>~ftp/pub/FreeBSD/distfiles</filename>.
|
|
Restrições de acesso foram implementadas para garantir que
|
|
apenas os clientes de compilação tenham acesso a este
|
|
diretório.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="release">
|
|
<title>Compilando Pacotes para uma Versão Específica</title>
|
|
|
|
<para>Ao compilar pacotes para uma versão específica do &os;,
|
|
pode ser necessário atualizar manualmente as árvores do
|
|
<literal>ports</literal> e do <literal>src</literal> para a
|
|
<literal>tag</literal> da versão desejada e usar as opções
|
|
<literal>-nocvs</literal> e
|
|
<literal>-noportscvs</literal>.</para>
|
|
|
|
<para>Para compilar conjuntos de pacotes que serão usados em um
|
|
CD-ROM, use a opção <literal>-cdrom</literal> para o comando
|
|
<command>dopackages</command>.</para>
|
|
|
|
<para>Se não houver espaço em disco disponível no
|
|
<literal>cluster</literal>, use <literal>-nodistfiles</literal>
|
|
para que os <literal>distfiles</literal> não sejam
|
|
baixados.</para>
|
|
|
|
<para>Após completar a compilação inicial, reinicie a compilação
|
|
com <literal>-restart -fetch-original</literal> para baixar os
|
|
<literal>distfiles</literal> atualizados. Então, uma vez que a
|
|
compilação tiver sido pós-processada, faça um inventário da
|
|
lista de arquivos baixados:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd <replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable></userinput>
|
|
&prompt.user; <userinput>find distfiles > distfiles-<replaceable>${release}</replaceable></userinput></screen>
|
|
|
|
<para>Este arquivo de inventário normalmente fica localizado em
|
|
<filename>i386/<replaceable>${branch}</replaceable></filename>
|
|
no nó principal do <literal>cluster</literal>.</para>
|
|
|
|
<para>Isto é útil para ajudar na limpeza periódica dos
|
|
<literal>distfiles</literal> do <hostid>ftp-master</hostid>.
|
|
Quando o espaço se torna escasso, os
|
|
<literal>distfiles</literal> das versões recentes podem ser
|
|
mantidos, enquanto outros podem ser jogados fora.</para>
|
|
|
|
<para>Uma vez que o <foreignphrase>upload</foreignphrase> dos
|
|
<literal>distfiles</literal> tenha sido feito (veja abaixo), o
|
|
conjunto de pacotes da versão final deve ser criado. Para se
|
|
assegurar, execute manualmente o <literal>script</literal>
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/cdrom.sh</filename>
|
|
para certificar-se de que todos os pacotes com distribuição
|
|
restrita via CD-ROM e todos os <literal>distfiles</literal>
|
|
foram removidos. Então, copie o diretório
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/packages</filename>
|
|
para
|
|
<filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/packages-<replaceable>${release}</replaceable></filename>.
|
|
Uma vez que os pacotes tenham sido movidos com segurança,
|
|
contate o &a.re; e informe-os da localização dos pacotes do
|
|
<literal>release</literal>.</para>
|
|
|
|
<para>Lembre-se de coordenar com o &a.re; sobre o
|
|
<literal>timing</literal> e o status das compilações do
|
|
<literal>release</literal>.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="uploading">
|
|
<title><foreignphrase>Upload</foreignphrase> dos Pacotes</title>
|
|
|
|
<para>Uma vez que a compilação tenha terminado, os pacotes e/ou
|
|
<literal>distfiles</literal> podem ser transferidos para o
|
|
<hostid>ftp-master</hostid> para serem propagados para a rede de
|
|
espelhos FTP. Se a compilação foi executada com a opção
|
|
<literal>-nofinish</literal>, então certifique-se de executar em
|
|
seguida o comando <command>dopackages -finish</command> para
|
|
realizar o pós-processamento dos pacotes (remover pacotes
|
|
marcados como <literal>RESTRICTED</literal> ou como
|
|
<literal>NO_CDROM</literal> onde for apropriado, remover pacotes
|
|
não listados no <filename>INDEX</filename>, remover do
|
|
<filename>INDEX</filename> as referências para pacotes não
|
|
compilados, e gerar um sumário
|
|
<filename>CHECKSUM.MD5</filename>); e dos
|
|
<literal>distfiles</literal> (movê-los do diretório temporário
|
|
<filename>distfiles/.pbtmp</filename> para o diretório
|
|
<filename>distfiles/</filename> e remover os
|
|
<literal>distfiles</literal> marcados como
|
|
<literal>RESTRICTED</literal> e
|
|
<literal>NO_CDROM</literal>).</para>
|
|
|
|
<para>É recomendado que se execute manualmente os
|
|
<literal>scripts</literal> <command>restricted.sh</command> e/ou
|
|
<command>cdrom.sh</command> após a finalização do
|
|
<command>dopackages</command>, apenas por segurança. Execute o
|
|
<literal>script</literal> <command>restricted.sh</command> antes
|
|
de fazer o <foreignphrase>upload</foreignphrase> para o
|
|
<hostid>ftp-master</hostid>, em seguida, execute
|
|
<command>cdrom.sh</command> antes de preparar o conjunto final
|
|
de pacotes para um <literal>release</literal>.</para>
|
|
|
|
<para>Os subdiretórios de pacotes são nomeados de acordo com a
|
|
versão e <literal>branch</literal> ao qual se destinam.
|
|
Por exemplo:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>packages-7.2-release</literal></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>packages-7-stable</literal></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>packages-8-stable</literal></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>packages-9-stable</literal></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>packages-10-current</literal></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note><para>Alguns destes diretórios no
|
|
<hostid>ftp-master</hostid> são na verdade
|
|
<literal>links</literal> simbólicos. Por exemplo:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><literal>packages-stable</literal></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>packages-current</literal></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Certifique-se de que você está movendo os novos pacotes
|
|
para um diretório de destino <emphasis>real</emphasis>, e não
|
|
para um dos <literal>links</literal> simbólicos que apontam
|
|
para ele.</para>
|
|
</note>
|
|
|
|
<para>Se você está preparando um conjunto de pacotes completamente
|
|
novo (por exemplo, para um novo <literal>release</literal>),
|
|
copie os pacotes para a área de teste do
|
|
<hostid>ftp-master</hostid> executando algo como mostrado
|
|
abaixo:</para>
|
|
|
|
<screen>&prompt.root; <userinput>cd /var/portbuild/<replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable></userinput>
|
|
&prompt.root; <userinput>tar cfv - packages/ | ssh portmgr@ftp-master tar xfC - w/ports/<replaceable>${arch}</replaceable>/tmp/<replaceable>${subdir}</replaceable></userinput></screen>
|
|
|
|
<para>Em seguida, entre no <hostid>ftp-master</hostid> e verifique
|
|
se o conjunto de pacotes foi transferido com sucesso, remova o
|
|
conjunto de pacotes que o novo conjunto vai substituir (em
|
|
<filename>~/w/ports/<replaceable>${arch}</replaceable></filename>),
|
|
e mova o novo conjunto para o local. (<literal>w/</literal> é
|
|
apenas um atalho.)</para>
|
|
|
|
<para>Para compilações incrementais, o
|
|
<foreignphrase>upload</foreignphrase> deve ser feito usando o
|
|
<command>rsync</command> para não colocar muita pressão nos
|
|
espelhos.</para>
|
|
|
|
<para><emphasis>SEMPRE</emphasis> use o <command>rsync</command>
|
|
primeiro com a opção <literal>-n</literal> e verifique a saída
|
|
do comando para assegurar-se que não existem problemas. Se
|
|
parece estar tudo bem, execute novamente o
|
|
<command>rsync</command> sem a opção <literal>-n</literal>.
|
|
</para>
|
|
|
|
<para>Exemplo de sintaxe do comando <command>rsync</command> para
|
|
o <foreignphrase>upload</foreignphrase> incremental de
|
|
pacotes:</para>
|
|
|
|
<screen>&prompt.root; <userinput>rsync -n -r -v -l -t -p --delete packages/ portmgr@ftp-master:w/ports/<replaceable>${arch}</replaceable>/<replaceable>${subdir}</replaceable>/ | tee log</userinput></screen>
|
|
|
|
<para>Os <literal>distfiles</literal> devem ser transferidos
|
|
utilizando-se o <literal>script</literal>
|
|
<command>cpdistfiles</command>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>/var/portbuild/scripts/cpdistfiles <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> <replaceable>${buildid}</replaceable> [-yesreally] | tee log2</userinput></screen>
|
|
|
|
<para>A execução manual deste processo é um procedimento
|
|
obsoleto.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="expbuilds">
|
|
<title>Compilação de <literal>Patches</literal>
|
|
Experimentais</title>
|
|
|
|
<para>Compilações de <literal>patches</literal> experimentais são
|
|
executadas de tempos em tempos para novas funções ou correções
|
|
de defeitos na infraestrutura do <literal>ports</literal> (isto
|
|
é, <filename>bsd.port.mk</filename>), ou para testar
|
|
atualizações em grande escala. A qualquer momento podem haver
|
|
vários <literal>patches</literal> de <literal>branchs</literal>
|
|
experimentais simultâneos, como o <literal>8-exp</literal> na
|
|
arquitetura amd64.</para>
|
|
|
|
<para>Geralmente, a compilação de <literal>patches</literal>
|
|
experimentais é executada da mesma forma que qualquer outra
|
|
compilação, exceto que você deve primeiro atualizar a árvore de
|
|
<literal>ports</literal> para a última versão e, em seguida,
|
|
aplicar os seus <literal>patches</literal>. Para fazer o primeiro,
|
|
você pode usar o seguinte:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cvs -R update -dP > update.out</userinput>
|
|
&prompt.user; <userinput>date > cvsdone</userinput></screen>
|
|
|
|
<para>Essa é a simulação mais próxima do que o
|
|
<literal>script</literal> <literal>dopackages</literal> faz.
|
|
(Embora o <filename>cvsdone</filename> seja meramente
|
|
informativo, ele pode ser útil.)</para>
|
|
|
|
<para>Você precisará editar o <filename>update.out</filename> para
|
|
procurar por linhas que comecem com <literal>^M</literal>,
|
|
<literal>^C</literal>, ou <literal>^?</literal> para que possa
|
|
corrigi-las.</para>
|
|
|
|
<para>É 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
|
|
<literal>commit</literal> final, para se certificar de que você
|
|
está realizando o <literal>commit</literal> exatamente daquilo
|
|
que testou.</para>
|
|
|
|
<para>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 <literal>home</literal> freefall
|
|
<hostid>freefall</hostid>. Não use o <filename>tmp/</filename>;
|
|
pois a <hostid>pointyhat</hostid> executa ele mesmo alguma
|
|
versão do <literal>-CURRENT</literal>, você pode esperar por
|
|
reinicializações (no mínimo para atualizações).</para>
|
|
|
|
<para>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 <literal>branch</literal> em que os
|
|
<literal>patches</literal> experimentais foram baseados para a
|
|
arquitetura &i386; (atualmente esta é o <literal>8</literal>).
|
|
Quando estiver preparando a compilação dos
|
|
<literal>patches</literal> experimentais, faça o
|
|
<literal>checkout</literal> da árvore do
|
|
<literal>ports</literal> e do <literal>src</literal> 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.</para>
|
|
|
|
<para>Uma vez terminada a compilação, compare as falhas da
|
|
compilação de controle com as da compilação dos
|
|
<literal>patches</literal> experimentais. Para facilitar, use
|
|
os seguintes comandos (assumindo o <literal>branch 8</literal>
|
|
como <literal>branch</literal> de controle, e o
|
|
<literal>8-exp</literal> como <literal>branch</literal>
|
|
experimental):</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd /var/portbuild/i386/8-exp/errors</userinput>
|
|
&prompt.user; <userinput>find . -name \*.log\* | sort > /tmp/8-exp-errs</userinput>
|
|
&prompt.user; <userinput>cd /var/portbuild/i386/8/errors</userinput>
|
|
&prompt.user; <userinput>find . -name \*.log\* | sort > /tmp/8-errs</userinput></screen>
|
|
|
|
<note><para>Se já faz muito tempo desde que a última compilação
|
|
foi finalizada, os <literal>logs</literal> podem ter sido
|
|
compactados automaticamente com
|
|
<application>bzip2</application>. Nesse caso você deve usar
|
|
<literal>sort | sed 's,\.bz2,,g'</literal> em seu
|
|
lugar.</para></note>
|
|
|
|
<screen>&prompt.user; <userinput>comm -3 /tmp/8-errs /tmp/8-exp-errs | less</userinput></screen>
|
|
|
|
<para>Este último comando vai gerar um relatório com duas colunas.
|
|
A primeira coluna contém os <literal>ports</literal> que
|
|
falharam na compilação de controle, mas não na compilação com
|
|
<literal>patches</literal> experimentais; a segunda é o inverso
|
|
As razões para o <literal>port</literal> estar na primeira
|
|
coluna incluem:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>O <literal>port</literal> 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)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>O <literal>port</literal> foi corrigido pelos
|
|
<literal>patches</literal> experimentais na compilação
|
|
experimental
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>O <literal>port</literal> não foi compilado na
|
|
compilação com <literal>patches</literal> experimentais devido
|
|
a falha de uma dependência
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Razões para o <literal>port</literal> aparecer na segunda
|
|
coluna incluem:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>O <literal>port</literal> foi quebrado pelos
|
|
<literal>patches</literal> experimentais [1]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>O <literal>port</literal> foi atualizado desde a
|
|
compilação de controle e deixou de compilar [2]
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>O <literal>port</literal> foi quebrado devido a um erro
|
|
temporário (por exemplo, site FTP fora do ar, erro do pacote
|
|
cliente, etc.)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Ambas as colunas devem ser investigadas e as razões para os
|
|
erros entendidas antes do <literal>commit</literal> do conjunto
|
|
de <literal>patches</literal> experimentais. Para diferenciar
|
|
entre o [1] e o [2] acima, você pode recompilar os pacotes
|
|
afetados sob o <literal>branch</literal> de controle:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd /var/portbuild/i386/8/ports</userinput></screen>
|
|
|
|
<note><para>Certifique-se de atualizar esta árvore com o
|
|
<literal>cvs update</literal> para a mesma data da árvore dos
|
|
<literal>patches</literal> experimentais.</para></note>
|
|
|
|
<para>O seguinte comando vai configurar o
|
|
<literal>branch</literal> de controle para a
|
|
compilação parcial (antigo código base):</para>
|
|
|
|
<screen>&prompt.user; <userinput>/var/portbuild/scripts/dopackages.8 -noportscvs -nobuild -nocvs -nofinish</userinput></screen>
|
|
|
|
<para>As compilações devem ser executadas a partir do diretório
|
|
<literal>packages/All</literal>. Este diretório deve estar
|
|
vazio inicialmente, exceto pelo <literal>link</literal>
|
|
simbólico do Makefile. Se este <literal>link</literal>
|
|
simbólico não existir, ele deve ser criado:</para>
|
|
|
|
<screen>&prompt.user; <userinput>cd /var/portbuild/i386/8/packages/All</userinput>
|
|
&prompt.user; <userinput>ln -sf ../../Makefile .</userinput>
|
|
&prompt.user; <userinput>make -k -j<#> <list of packages to build></userinput></screen>
|
|
|
|
<note><para>O <#> é o número de compilações paralelas para
|
|
tentar. Normalmente isso é a soma dos pesos listados em
|
|
<filename>/var/portbuild/i386/mlist</filename>, a menos que você
|
|
tenha uma razão para executar uma compilação mais pesada ou
|
|
leve.</para>
|
|
|
|
<para>A lista de pacotes para compilar deve ser uma lista do nome
|
|
do pacote (incluindo as versões) como aparece no
|
|
<filename>INDEX</filename>. O <literal>PKGSUFFIX</literal>
|
|
(isto é, .tgz ou .tbz) é opcional.</para></note>
|
|
|
|
<para>Isto vai compilar apenas os pacotes listados, bem como
|
|
todas as suas dependências.</para>
|
|
|
|
<para>Você pode verificar o progresso da compilação parcial da
|
|
mesma forma que você faria com uma compilação normal.</para>
|
|
|
|
<para>Uma vez que todos os erros tenham sido resolvidos, você pode
|
|
efetuar o <literal>commit</literal> do conjunto de pacotes.
|
|
Após efetuar o <literal>commit</literal>, é de costume enviar um
|
|
e-mail para <ulink
|
|
url="mailto:ports@FreeBSD.org">ports@FreeBSD.org</ulink> e com
|
|
cópia para <ulink
|
|
url="mailto:ports-developers@FreeBSD.org">ports-developers@FreeBSD.org</ulink>,
|
|
informando as pessoas sobre as mudanças. Um resumo de todas as
|
|
mudanças também deve registrado no arquivo
|
|
<filename>/usr/ports/CHANGES</filename>.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="new-node">
|
|
<title>Como configurar um novo nó de compilação de pacotes</title>
|
|
|
|
<para>Antes de seguir estes passos, por favor, converse com o
|
|
<literal>portmgr</literal>.
|
|
</para>
|
|
|
|
<note>
|
|
<para>Devido à algumas doações generosas, o
|
|
<literal>portmgr</literal> não está mais procurando por
|
|
empréstimos de sistemas &i386; ou <literal>amd64</literal>.
|
|
No entanto, nós ainda estamos interessados no empréstimo de
|
|
sistemas <literal>tier-2</literal>.</para>
|
|
</note>
|
|
|
|
<sect2 id="node-requirements">
|
|
<title>Requisitos do nó</title>
|
|
|
|
<para>O <literal>portmgr</literal> ainda está trabalhando para
|
|
definir quais são características que um nó necessita possuir
|
|
para ser útil.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Capacidade de CPU: qualquer coisa abaixo de 500MHz
|
|
geralmente não é útil para a compilação de pacotes.</para>
|
|
|
|
<note>
|
|
<para>Nós somos capazes de ajustar o número de tarefas
|
|
enviadas para cada máquina, e nós geralmente ajustamos o
|
|
número para fazer uso de 100% da CPU.</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>RAM: O mínimo utilizável é 2G; o ideal é ter 8G
|
|
ou mais. Normalmente configuramos uma tarefa para cada
|
|
512M de RAM.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Disco: É necessário um mínimo de 20G para o sistema de
|
|
arquivos e de 32G para a area de <literal>swap</literal>.
|
|
O desempenho será melhor se múltiplos discos forem
|
|
utilizados, e configurados como <literal>geom</literal>
|
|
<literal>stripes</literal>. Os dados de desempenho
|
|
também estão em fase de definição.</para>
|
|
|
|
<note>
|
|
<para>A compilação de pacotes irá estressar as unidades
|
|
de disco até o seu limite (ou além dele). Esteja
|
|
consciente do que você está se voluntariando para
|
|
fazer!</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>largura de banda de rede: Ainda não existe um estudo
|
|
preciso, no entanto uma máquina configurada para 8
|
|
tarefas simultâneas se mostrou capaz de saturar um
|
|
link de internet a cabo.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="node-preparation">
|
|
<title>Preparação</title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Escolha um <literal>hostname</literal> único. Ele não
|
|
tem que ser um <literal>hostname</literal> resolvível
|
|
publicamente (ele pode ser um nome em sua rede
|
|
interna).</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Por padrão, a compilação de pacotes necessita que as
|
|
seguintes portas TCP estejam acessíveis: 22
|
|
(<literal>ssh</literal>), 414
|
|
(<literal>infoseek</literal>), e 8649
|
|
(<literal>ganglia</literal>). Se estas não estiverem
|
|
acessíveis, escolha outras e assegure-se de que um túnel
|
|
<command>ssh</command> esteja configurado (veja
|
|
abaixo).</para>
|
|
|
|
<para>(Nota: se você tem mais de uma máquina em seu site,
|
|
você vai precisar de uma porta TCP individual para cada
|
|
serviço em cada máquina, desta forma serão necessários
|
|
túneis <command>ssh</command>. Portanto, você
|
|
provavelmente precisará configurar o redirecionamento de
|
|
portas em seu <literal>firewall</literal>.)</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Decida se você vai inicializar localmente ou via
|
|
<literal>pxeboot</literal>. Você vai descobrir que é
|
|
mais fácil acompanhar as mudanças do
|
|
<literal>-current</literal> com a última opção,
|
|
especialmente se você tem várias máquinas em seu
|
|
site.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Escolha um diretório para manter as configurações dos
|
|
<literal>ports</literal> e os subdiretórios do
|
|
<command>chroot</command>. Pode ser melhor colocá-los em
|
|
uma partição dedicada. (Por exemplo:
|
|
<filename>/usr2/</filename>.)</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="node-src">
|
|
<title>Configurando o <literal>src</literal></title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Crie um diretório para armazenar a árvore dos fontes
|
|
do último <literal>-current</literal> e sincronize ela com
|
|
o repositório. (Uma vez que sua máquina provavelmente
|
|
será solicitada para compilar pacotes para o
|
|
<literal>-current</literal>, o <literal>kernel</literal>
|
|
que ela executa deve estar razoavelmente atualizado com o
|
|
<literal>bindist</literal> que será exportado por nossos
|
|
<literal>scripts</literal>.)</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Se você está usando <literal>pxeboot</literal>: crie
|
|
um diretório para armazenar os arquivos de instalação.
|
|
Você provavelmente vai querer usar um subdiretório do
|
|
<filename>/pxeroot</filename>, por exemplo,
|
|
<filename>/pxeroot/<replaceable>${arch}</replaceable>-<replaceable>${branch}</replaceable></filename>.
|
|
Exporte como <makevar>DESTDIR</makevar>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Se você está realizando uma compilação para outra
|
|
plataforma, que não a instalada na máquina
|
|
(<foreignphrase>cross-building</foreignphrase>), exporte
|
|
<literal>TARGET_ARCH</literal>=<replaceable>${arch}</replaceable>.
|
|
</para>
|
|
<note>
|
|
<para>O procedimento para compilação cruzada de
|
|
<literal>ports</literal> ainda não está definido.</para>
|
|
</note>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Gere um arquivo de configuração para o
|
|
<literal>kernel</literal>. Inclua o
|
|
<literal>GENERIC</literal> (ou, se você está usando mais
|
|
que 3.5G de memória em um &i386;, o
|
|
<literal>PAE</literal>).</para>
|
|
<para>Opção requeridas:</para>
|
|
|
|
<screen>options NULLFS
|
|
options TMPFS</screen>
|
|
|
|
<para>Opções sugeridas:</para>
|
|
|
|
<screen>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</screen>
|
|
|
|
<para>Para o <literal>PAE</literal>, atualmente não é
|
|
possível carregar módulos. Portanto, se você está
|
|
executando uma arquitetura que suporta emulação binária
|
|
do Linux, você precisará adicionar:</para>
|
|
|
|
<screen>options COMPAT_LINUX
|
|
options LINPROCFS</screen>
|
|
|
|
<para>Também para o <literal>PAE</literal>, a partir de
|
|
12/09/2011 você precisa do seguinte. Isso precisa ser
|
|
investigado:</para>
|
|
|
|
<screen>nooption NFSD # New Network Filesystem Server
|
|
options NFSCLIENT # Network Filesystem Client
|
|
options NFSSERVER # Network Filesystem Server</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Como <username>root</username>, execute os passos
|
|
usuais de compilação, por exemplo:</para>
|
|
|
|
<screen>
|
|
<userinput>make -j4 buildworld</userinput>
|
|
<userinput>make buildkernel KERNCONF=<replaceable>${kernconf}</replaceable></userinput>
|
|
<userinput>make installkernel KERNCONF=<replaceable>${kernconf}</replaceable></userinput>
|
|
<userinput>make installworld</userinput></screen>
|
|
|
|
<para>Os passos de instalação usam o caminho especificado na
|
|
da váriavel <makevar>DESTDIR</makevar>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Personalize os arquivos em <filename>etc/</filename>.
|
|
O local no qual você fará isso, se no próprio cliente ou
|
|
em outra máquina, vai depender se você está usando ou não
|
|
o <literal>pxeboot</literal>.</para>
|
|
|
|
<para>Se você está usando <literal>pxeboot</literal>: crie
|
|
um subdiretório no
|
|
<filename><replaceable>${DESTDIR}</replaceable></filename>
|
|
chamado <filename>conf/</filename>. Crie um subdiretório
|
|
<filename>default/etc/</filename>, e (se seu
|
|
<literal>site</literal> vai hospedar vários nós),
|
|
subdiretórios
|
|
<filename><replaceable>${ip-address}</replaceable>/etc/</filename>
|
|
para os arquivos que vão sobrescrever as configurações
|
|
para os <literal>hosts</literal> individuais. (Você pode
|
|
achar útil criar um <literal>link</literal> simbólico de
|
|
cada um destes diretórios para um
|
|
<literal>hostname</literal>.) Copie todo o conteúdo do
|
|
<filename><replaceable>${DESTDIR}</replaceable>/etc/</filename>
|
|
para <filename>default/etc/</filename>; que é onde você
|
|
irá editar seus arquivos. Nos diretórios criados para
|
|
cada endereço IP, você provavelmente só irá necessitar
|
|
personalizar os arquivos
|
|
<filename>rc.conf</filename>.</para>
|
|
|
|
<para>Em ambos os casos, execute os seguintes passos:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Crie um usuário e grupo
|
|
<literal>ports-<replaceable>${arch}</replaceable></literal>.
|
|
Adicione o usuário ao grupo
|
|
<literal>wheel</literal>. Ele pode ter um
|
|
<literal>'*'</literal> no lugar da senha.</para>
|
|
|
|
<para>Crie o
|
|
<filename>/home/ports-<replaceable>${arch}/.ssh/</replaceable></filename>
|
|
e popule o arquivo
|
|
<filename>authorized_keys</filename> com as chaves
|
|
ssh apropriadas.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie os usuários:</para>
|
|
|
|
<screen>squid:*:100:100::0:0:User &:/usr/local/squid:/bin/sh
|
|
ganglia:*:102:102::0:0:User &:/usr/local/ganglia:/bin/sh</screen>
|
|
|
|
<para>E também os adicione ao arquivo
|
|
<filename>etc/group</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie os arquivos apropriados em
|
|
<filename>etc/.ssh/</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Edite o <filename>etc/crontab</filename> e
|
|
adicione o seguinte:</para>
|
|
|
|
<screen>* * * * * root /var/portbuild/scripts/client-metrics</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um <filename>etc/fstab</filename>
|
|
apropriado. (Se você tem várias máquinas
|
|
diferentes, você precisará colocar este arquivo nos
|
|
diretórios específicos de cada uma.)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Edite o <filename>etc/inetd.conf</filename> e
|
|
adicione o seguinte:</para>
|
|
|
|
<screen>infoseek stream tcp nowait nobody /var/portbuild/scripts/reportload</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Nós utilizamos o timezone <acronym>UTC</acronym>
|
|
no <literal>cluster</literal>:</para>
|
|
|
|
<screen>cp /usr/share/zoneinfo/Etc/UTC etc/localtime</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um <filename>etc/rc.conf</filename>
|
|
apropriado. (Se você está usando
|
|
<literal>pxeboot</literal>, e tem várias máquinas
|
|
diferentes, você precisará colocar este arquivo nos
|
|
diretórios específico de cada uma.)</para>
|
|
|
|
<para>Configurações recomendadas para nós
|
|
físicos:</para>
|
|
|
|
<screen>hostname="<replaceable>${hostname}</replaceable>"
|
|
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="<filename>/<replaceable>usr2</replaceable>/squid/logs</filename>"
|
|
squid_pidfile="<filename>/<replaceable>usr2</replaceable>/squid/logs/squid.pid</filename>"</screen>
|
|
|
|
<para>Configurações obrigatórias para nós baseados no
|
|
VMWare:</para>
|
|
|
|
<screen>vmware_guest_vmmemctl_enable="YES"
|
|
vmware_guest_guestd_enable="YES"</screen>
|
|
|
|
<para>Configurações recomendadas para nós baseados no
|
|
VMWare:</para>
|
|
|
|
<screen>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="<filename>/<replaceable>usr2</replaceable>/squid/logs</filename>"
|
|
squid_pidfile="<filename>/<replaceable>usr2</replaceable>/squid/logs/squid.pid</filename>"</screen>
|
|
|
|
<para>O &man.ntpd.8; <emphasis>não</emphasis> deve ser
|
|
habilitado para os nós baseados no VMWare.</para>
|
|
|
|
<para>Além disso, você pode optar por deixar o
|
|
<application>squid</application> desabilitado por
|
|
padrão, de modo a não ter um
|
|
<filename>/<replaceable>usr2</replaceable></filename>
|
|
persistente (o que deve economizar tempo na criação da
|
|
instância.) O trabalho ainda está em andamento.
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie o <filename>etc/resolv.conf</filename>, se
|
|
necessário.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Modifique o
|
|
<filename>etc/sysctl.conf</filename>:</para>
|
|
|
|
<screen>9a10,30
|
|
> kern.corefile=<filename>/<replaceable>usr2</replaceable>/%N.core</filename>
|
|
> 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</screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Se desejar, modifique o
|
|
<filename>etc/syslog.conf</filename> para mudar o
|
|
destino dos <literal>logs</literal> para
|
|
<literal>@pointyhat.freebsd.org</literal>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</step>
|
|
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="node-ports">
|
|
<title>Configurando os <literal>ports</literal></title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Instale os seguintes <literal>ports</literal>:</para>
|
|
|
|
<screen>net/rsync
|
|
security/openssh-portable (with HPN on)
|
|
security/sudo
|
|
sysutils/ganglia-monitor-core (with GMETAD off)
|
|
www/squid (with SQUID_AUFS on)</screen>
|
|
|
|
<para>Existe um trabalho em andamento para criar um
|
|
<literal>meta-port</literal>, mas ainda não está
|
|
completo.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Customize os arquivos em
|
|
<filename>usr/local/etc/</filename>. O local no qual
|
|
você fará isso, se no próprio cliente ou em outra
|
|
máquina, vai depender se você está usando ou não o
|
|
<literal>pxeboot</literal>.</para>
|
|
|
|
<note>
|
|
<para>O truque de usar
|
|
subdiretórios<filename>conf</filename> para
|
|
sobreescrever as opções padrões é menos eficaz aqui,
|
|
pois você precisa copiar todos os subdiretórios do
|
|
<filename>usr/</filename>. Este é um detalhe da
|
|
implementação de como o <literal>pxeboot</literal>
|
|
funciona.</para>
|
|
</note>
|
|
|
|
<para>Execute os seguintes passos:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Modifique o
|
|
<filename>usr/local/etc/gmond.conf</filename>:</para>
|
|
|
|
<screen>21,22c21,22
|
|
< name = "unspecified"
|
|
< owner = "unspecified"
|
|
---
|
|
> name = "<replaceable>${arch}</replaceable> package build cluster"
|
|
> owner = "portmgr@FreeBSD.org"
|
|
24c24
|
|
< url = "unspecified"
|
|
---
|
|
> url = "http://pointyhat.freebsd.org"</screen>
|
|
|
|
<para>Se existirem máquinas de mais de um
|
|
<literal>cluster</literal> no mesmo domínio
|
|
<literal>multicast</literal> (basicamente = LAN),
|
|
então altere os grupos de <literal>multicast</literal>
|
|
para valores diferentes (.71, .72, etc).</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie o
|
|
<filename>usr/local/etc/rc.d/portbuild.sh</filename>,
|
|
usando um valor apropriado para
|
|
<literal>scratchdir</literal>:</para>
|
|
|
|
<screen>#!/bin/sh
|
|
#
|
|
# Configure a package build system post-boot
|
|
|
|
scratchdir=<filename>/<replaceable>usr2</replaceable></filename>
|
|
|
|
ln -sf ${scratchdir}/portbuild /var/
|
|
|
|
# Identify builds ready for use
|
|
cd /var/portbuild/<replaceable>${arch}</replaceable>
|
|
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</screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Modifique o
|
|
<filename>usr/local/etc/squid/squid.conf</filename>:</para>
|
|
|
|
<screen>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</screen>
|
|
|
|
<para>Modifique também o <filename>usr/local</filename>
|
|
para
|
|
<filename><replaceable>usr2</replaceable></filename>
|
|
em <literal>cache_dir</literal>,
|
|
<literal>access_log</literal>,
|
|
<literal>cache_log</literal>,
|
|
<literal>cache_store_log</literal>,
|
|
<literal>pid_filename</literal>,
|
|
<literal>netdb_filename</literal>,
|
|
<literal>coredump_dir</literal>.
|
|
</para>
|
|
|
|
<para>E finalmente, mude o esquema de armazenamento do
|
|
<literal>cache_dir</literal>, de
|
|
<literal>ufs</literal> para <literal>aufs</literal>
|
|
(o qual oferece uma melhor performance).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Configure o <command>ssh</command>: copie os
|
|
arquivos do <filename>/etc/ssh</filename> para
|
|
<filename>/usr/local/etc/ssh</filename> e adicione
|
|
<literal>NoneEnabled yes</literal> ao
|
|
<filename>sshd_config</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Modifique o
|
|
<filename>usr/local/etc/sudoers</filename>:</para>
|
|
|
|
<screen>38a39,42
|
|
>
|
|
> # local changes for package building
|
|
> %wheel ALL=(ALL) ALL
|
|
> ports-<replaceable>${arch}</replaceable> ALL=(ALL) NOPASSWD: ALL</screen>
|
|
|
|
</listitem>
|
|
</itemizedlist>
|
|
</step>
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="node-configuration">
|
|
<title>Configuração no próprio cliente</title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Entre no diretório <literal>port/package</literal> que
|
|
você escolheu acima, por exemplo,
|
|
<command>cd <filename>/<replaceable>usr2</replaceable></filename></command>.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Execute como root:</para>
|
|
|
|
<screen><userinput>mkdir portbuild</userinput>
|
|
<userinput>chown ports-<replaceable>${arch}</replaceable>:ports-<replaceable>${arch}</replaceable> portbuild</userinput>
|
|
<userinput>mkdir pkgbuild</userinput>
|
|
<userinput>chown ports-<replaceable>${arch}</replaceable>:ports-<replaceable>${arch}</replaceable> pkgbuild</userinput>
|
|
<userinput>mkdir squid</userinput>
|
|
<userinput>mkdir squid/cache</userinput>
|
|
<userinput>mkdir squid/logs</userinput>
|
|
<userinput>chown -R squid:squid squid</userinput></screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Se os clientes preservam o conteúdo do
|
|
<filename>/var/portbuild</filename> entre as suas
|
|
inicializações, então eles também deverão preservar o
|
|
<filename>/tmp</filename> ou então revalidar as
|
|
compilações disponíveis no momento do boot (veja o
|
|
<literal>script</literal> nas máquinas
|
|
<literal>amd64</literal>). Eles também devem limpar os
|
|
<literal>chroots</literal> obsoletos das compilações
|
|
anteriores antes de criar o
|
|
<filename>/tmp/.boot_finished</filename>.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Inicie o cliente.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Como root, crie a estrutura de diretórios do
|
|
<command>squid</command>:</para>
|
|
|
|
<screen><userinput>squid -z</userinput></screen>
|
|
</step>
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="pointyhat-configuration">
|
|
<title>Configuração no <literal>pointyhat</literal></title>
|
|
|
|
<para>Estes passos precisam ser feitos por um
|
|
<literal>portmgr</literal>, autenticado como o usuário
|
|
<literal>ports-<replaceable>${arch}</replaceable></literal>,
|
|
no <hostid>pointyhat</hostid>.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Se alguma das portas <acronym>TCP</acronym> padrão não
|
|
estiver disponível (veja acima), você precisará criar um
|
|
túnel <command>ssh</command> para ela e deverá incluí-lo
|
|
no <filename>crontab</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Adicione uma entrada em
|
|
<filename>/home/ports-<replaceable>${arch}</replaceable>/.ssh/config</filename>
|
|
para especificar o endereço IP público, a porta TCP para o
|
|
<command>ssh</command>, o usuário, e qualquer outra
|
|
informação necessária.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Crie o
|
|
<filename>/var/portbuild/<replaceable>${arch}</replaceable>/clients/bindist-<replaceable>${hostname}</replaceable>.tar</filename>.
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Copie um arquivos dos existentes para usar como
|
|
modelo e descompacte-o em um diretório
|
|
temporário.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Personalize o <filename>etc/resolv.conf</filename>
|
|
para o <literal>site</literal> local.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Personalize o <filename>etc/make.conf</filename>
|
|
para a busca de arquivo no FTP local. Nota: a
|
|
anulação da variável
|
|
<makevar>MASTER_SITE_BACKUP</makevar> deve ser comum
|
|
para todos os nós, mas a primeira entrada em
|
|
<makevar>MASTER_SITE_OVERRIDE</makevar> deve ser o
|
|
espelho FTP mais próximo. Por exemplo:</para>
|
|
|
|
<screen><command>
|
|
.if defined(FETCH_ORIGINAL)
|
|
MASTER_SITE_BACKUP=
|
|
.else
|
|
MASTER_SITE_OVERRIDE= \
|
|
ftp://<replaceable>friendly-local-ftp-mirror</replaceable>/pub/FreeBSD/ports/distfiles/${DIST_SUBDIR}/ \
|
|
ftp://${BACKUP_FTP_SITE}/pub/FreeBSD/distfiles/${DIST_SUBDIR}/
|
|
.endif</command></screen>
|
|
|
|
</listitem>
|
|
<listitem>
|
|
<para>Empacote-o com <command>tar</command> e mova
|
|
para o local correto.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Dica: você precisará de um destes para cada máquina;
|
|
no entanto, se você tem várias máquinas no mesmo site, você
|
|
deve criar um local específico para este
|
|
<literal>site</literal> (por exemplo, em
|
|
<filename>/var/portbuild/conf/clients/</filename>) e criar
|
|
um <literal>link</literal> simbólico para ele.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Crie o
|
|
<filename>/var/portbuild/<replaceable>${arch}</replaceable>/portbuild-<replaceable>${hostname}</replaceable></filename>
|
|
utilizando um dos existentes como guia. O conteúdo deste
|
|
arquivo sobrescreve as configurações de
|
|
<filename>/var/portbuild/<replaceable>${arch}</replaceable>/portbuild.conf</filename>.</para>
|
|
|
|
<para>Sugestão de valores:</para>
|
|
|
|
<screen>disconnected=1
|
|
http_proxy="http://localhost:3128/"
|
|
squid_dir=<filename>/<replaceable>usr2</replaceable>/squid</filename>
|
|
scratchdir=<filename>/<replaceable>usr2</replaceable>/pkgbuild</filename>
|
|
client_user=ports-<replaceable>${arch}</replaceable>
|
|
sudo_cmd="sudo -H"
|
|
rsync_gzip=-z
|
|
|
|
infoseek_host=localhost
|
|
infoseek_port=<replaceable>${tunelled-tcp-port}</replaceable></screen>
|
|
|
|
<para>Outros valores possíveis:</para>
|
|
|
|
<screen>use_md_swap=1
|
|
md_size=9g
|
|
use_zfs=1
|
|
scp_cmd="/usr/local/bin/scp"
|
|
ssh_cmd="/usr/local/bin/ssh"
|
|
</screen>
|
|
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>Os passos abaixo precisam ser executados por um
|
|
<literal>portmgr</literal> autenticado como
|
|
<literal>root</literal> no <hostid>pointyhat</hostid>.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Adicione o endereço IP público em
|
|
<filename>/etc/hosts.allow</filename>. (Lembre-se, várias
|
|
máquinas podem estar sob o mesmo endereço IP.)</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Adicione uma entrada <literal>data_source</literal>
|
|
para
|
|
<filename>/usr/local/etc/gmetad.conf</filename>:</para>
|
|
<para>
|
|
<literal>data_source "<replaceable>arch</replaceable>/<replaceable>location</replaceable> Package Build Cluster" 30 <replaceable>hostname</replaceable></literal>
|
|
</para>
|
|
|
|
<para>Você precisará reiniciar o
|
|
<filename>gmetad</filename>.
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="node-enabling">
|
|
<title>Habilitando o nó</title>
|
|
|
|
<para>Estes passos precisam ser executados por um
|
|
<literal>portmgr</literal> autenticado como
|
|
<literal>ports-<replaceable>arch</replaceable></literal> no
|
|
<hostid>pointyhat</hostid>.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Certifique-se que o <literal>ssh</literal> está
|
|
funcionando executando <command>ssh
|
|
<replaceable>hostname</replaceable></command>.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Crie os arquivos em
|
|
<filename>/var/portbuild/scripts/</filename> executando
|
|
algo como <command>/var/portbuild/scripts/dosetupnode
|
|
<replaceable>arch</replaceable>
|
|
<replaceable>major</replaceable> latest
|
|
<replaceable>hostname</replaceable></command>. Verifique
|
|
se os arquivos foram criados no diretório.
|
|
</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Teste as outras portas TCP executando <command>telnet
|
|
<replaceable>hostname</replaceable>
|
|
<replaceable>portnumber</replaceable></command>.
|
|
A porta <literal>414</literal> (ou seu túnel) deve dar-lhe
|
|
algumas linhas com informações de status, incluindo
|
|
<literal>arch</literal> e <literal>osversion</literal>;
|
|
A porta <literal>8649</literal> deve retornar um
|
|
<literal>XML</literal> do
|
|
<literal>ganglia</literal>.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>Esses passos precisam ser executados por um
|
|
<literal>portmgr</literal> autenticado como
|
|
<literal>root</literal> no <hostid>pointyhat</hostid>.
|
|
</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Informe o <filename>qmanager</filename> sobre o nó.
|
|
Por exemplo:</para>
|
|
|
|
<para><command>python <replaceable>path</replaceable>/qmanager/qclient add
|
|
name=<replaceable>uniquename</replaceable>
|
|
arch=<replaceable>arch</replaceable>
|
|
osversion=<replaceable>osversion</replaceable>
|
|
numcpus=<replaceable>number</replaceable>
|
|
haszfs=0
|
|
online=1
|
|
domain=<replaceable>domain</replaceable>
|
|
primarypool=package
|
|
pools="package all" maxjobs=1
|
|
acl="ports-<replaceable>arch</replaceable>,deny_all"
|
|
</command></para>
|
|
</step>
|
|
</procedure>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="new-branch">
|
|
<title>Como configurar um novo <literal>branch</literal> do
|
|
&os;</title>
|
|
|
|
<para>Quando um novo <literal>branch</literal> é criado, é
|
|
necessário efetuar alguns ajustes no sistema para especificar
|
|
que o <literal>branch</literal> anterior não mais corresponde ao
|
|
<literal>HEAD</literal>. As seguintes instruções se aplicam ao
|
|
número do <literal>branch</literal>
|
|
<emphasis>anterior</emphasis>:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>(novo código base) Edite o
|
|
<filename>/var/portbuild/conf/server.conf</filename>
|
|
e faça as seguintes alterações:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Adicione o <replaceable>new-branch</replaceable>
|
|
na variável <makevar>SRC_BRANCHES</makevar>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Para o <literal>branch</literal> que anteriormente
|
|
era o <literal>head</literal>, mude o
|
|
<makevar>SRC_BRANCH_<replaceable>branch</replaceable>_TAG</makevar>
|
|
para
|
|
<literal>RELENG_<replaceable>branch</replaceable>_0</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Adicione
|
|
<makevar>SRC_BRANCH_<replaceable>new-branch</replaceable>_TAG</makevar><literal>=.</literal>
|
|
(o ponto é literal).</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(novo código base) Execute o
|
|
<command>/var/portbuild/updatesnap</command>
|
|
manualmente.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Apenas para o antigo código base) Crie um novo sistema
|
|
de arquivos <application>zfs</application> para os
|
|
fontes:</para>
|
|
|
|
<screen>zfs create a/snap/src-<replaceable>branch</replaceable></screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base):
|
|
Obtenha uma cópia da árvore de fontes do
|
|
<literal>src</literal> apartir do SVN e deposite a mesma
|
|
no novo sistema de arquivos:</para>
|
|
|
|
<screen>cvs -Rq -d /r/ncvs co -d src-<replaceable>branch</replaceable>-r RELENG_<replaceable>branch</replaceable></screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Edite a
|
|
cópia principal do
|
|
<filename>Tools/portbuild/portbuild.conf</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Edite a
|
|
cópia do arquivo acima para cada uma das arquiteturas em
|
|
<filename>/var/portbuild/<replaceable>arch</replaceable>/portbuild.conf</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Edite o
|
|
<filename>/var/portbuild/scripts/buildenv</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Adicione
|
|
um <literal>link</literal> simbólico de
|
|
<filename>/var/portbuild/scripts/dopackages</filename> para
|
|
<filename>/var/portbuild/scripts/dopackages.<replaceable>branch</replaceable></filename>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Modifique
|
|
as variáveis <makevar>HEAD_BRANCH</makevar> e
|
|
<makevar>NON_HEAD_BRANCHES</makevar> no arquivo
|
|
<filename>/var/portbuild/scripts/updatesnap</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Adicione
|
|
o diretório <literal>snap</literal> ao arquivo
|
|
<filename>/var/portbuild/scripts/zexpire</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Crie os
|
|
<literal>links</literal> simbólicos para uso do servidor
|
|
web no diretório
|
|
<filename>/var/portbuild/errorlogs/</filename>:</para>
|
|
|
|
<screen>ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/bak/errors <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-full
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/bak/logs <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-full-logs
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/errors <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-latest
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/logs <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-latest-logs
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/bak/packages <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-packages-full
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/packages <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-packages-latest</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Inicie a compilação para o <literal>branch</literal>
|
|
executando:</para>
|
|
|
|
<screen>build create <replaceable>arch</replaceable> <replaceable>branch</replaceable></screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link linkend="setup">Crie o
|
|
<filename>bindist.tar</filename></link>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="old-branch">
|
|
<title>Como excluir um <literal>branch</literal> que deixou de
|
|
ser suportado pelo &os;</title>
|
|
|
|
<para>Quando um <literal>branch</literal> antigo deixa de ser
|
|
suportado, existem algumas coisas a serem feitas para que não
|
|
fique sujeira para trás.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>(novo código base) Edite o
|
|
<filename>/var/portbuild/conf/server.conf</filename> e faça
|
|
as seguintes alterações:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Apague o <replaceable>old-branch</replaceable> da
|
|
variável <makevar>SRC_BRANCHES</makevar>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Remova o
|
|
<makevar>SRC_BRANCH_<replaceable>old-branch</replaceable>_TAG</makevar>
|
|
<literal>=<replaceable>whatever</replaceable></literal></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(novo e antigo código base):
|
|
<command>umount a/snap/src-<replaceable>old-branch</replaceable>/src;
|
|
umount a/snap/src-<replaceable>old-branch</replaceable>;
|
|
zfs destroy -r a/snap/src-<replaceable>old-branch</replaceable></command></para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>(novo e antigo código base) Provavelmente você
|
|
encontrará os seguintes arquivos e <literal>links</literal>
|
|
simbólicos em <filename>/var/portbuild/errorlogs/</filename>
|
|
os quais podem ser removidos:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Arquivos chamados
|
|
<filename>*-<replaceable>old_branch</replaceable>-failure.html</filename>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Arquivos chamados
|
|
<filename>buildlogs_*-<replaceable>old_branch</replaceable>-*-logs.txt</filename>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>Links</literal> simbólicos chamados
|
|
<filename>*-<replaceable>old_branch</replaceable>-previous*</filename>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><literal>Links</literal> simbólicos chamados
|
|
<filename>*-<replaceable>old_branch</replaceable>-latest*</filename>
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="rebase-branch">
|
|
<title>Como regerar pacotes baseados em outra versão menor do
|
|
&os;</title>
|
|
|
|
<para>Desde 2011 a filosofia da compilação de pacotes diz que
|
|
devemos compilá-los baseados <emphasis>na versão mais antiga
|
|
suportada</emphasis> de cada <literal>branch</literal>. Por
|
|
exemplo: se no <literal>RELENG-8</literal> as seguintes versões
|
|
são suportadas: 8.1, 8.2, 8.3; então o
|
|
<literal>packages-8-stable</literal> deve ser compilado a partir
|
|
da versão 8.1.</para>
|
|
|
|
<para>Quando uma versão chega ao fim de sua vida
|
|
(<literal>End-Of-Life</literal>, veja o <ulink
|
|
url="http://www.freebsd.org/security/index.html#supported-branches">quadro</ulink>),
|
|
uma compilação completa (não incremental!) dos pacotes deve ser
|
|
realizada e enviada para os servidores de distribuição.</para>
|
|
|
|
<para>Os procedimentos para o novo código base são os que
|
|
seguem abaixo:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Edite o
|
|
<filename>/var/portbuild/conf/server.conf</filename> e faça
|
|
as seguintes mudanças:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Altere o
|
|
<makevar>SRC_BRANCH_<replaceable>branch</replaceable>_TAG</makevar> para
|
|
<literal>RELENG_<replaceable>branch</replaceable>_<replaceable>N</replaceable></literal>
|
|
no qual o <literal>N</literal> é versão menor
|
|
mais antiga para este ramo.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Execute o <command>
|
|
/var/portbuild/updatesnap</command> manualmente.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Execute o <command>
|
|
dopackages</command> com a opção <literal>-nobuild</literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Siga os <link linkend="setup">procedimentos de
|
|
configuração</link>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Agora você já pode executar o <command>
|
|
dopackages</command> sem a opção <literal>-nobuild</literal>.</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>O procedimento para o antigo código base fica como um
|
|
exercício para o leitor.</para>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="new-arch">
|
|
<title>Como configurar uma nova arquitetura</title>
|
|
|
|
<note>
|
|
<para>Os passos iniciais precisam ser feitos usando
|
|
<application>sudo</application>.</para>
|
|
</note>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Crie um novo usuário e grupo
|
|
<literal>ports-<replaceable>arch</replaceable></literal>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<screen>mkdir /var/portbuild/<replaceable>arch</replaceable></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um novo sistema de arquivo
|
|
<application>zfs</application>:</para>
|
|
|
|
<screen>zfs create -o mountpoint=/a/portbuild/<replaceable>arch</replaceable> a/portbuild/<replaceable>arch</replaceable></screen>
|
|
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<screen>
|
|
chown ports-<replaceable>arch</replaceable>:portmgr /var/portbuild/<replaceable>arch</replaceable>;
|
|
chmod 755 /var/portbuild/<replaceable>arch</replaceable>;
|
|
cd /var/portbuild/<replaceable>arch</replaceable></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie e popule o diretório
|
|
<filename>.ssh</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um diretório para os <literal>logs</literal> de
|
|
compilação e para os <literal>logs</literal> de
|
|
erros:</para>
|
|
|
|
<screen>mkdir /dumpster/pointyhat/<replaceable>arch</replaceable>/archive</screen>
|
|
|
|
<note>
|
|
<para>É possível que
|
|
<filename>/dumpster/pointyhat</filename> não tenha mais
|
|
espaço suficiente. Neste caso, crie o diretório dos
|
|
arquivos como
|
|
<filename>/dumpster/pointyhat/<replaceable>arch</replaceable>/archive</filename>
|
|
e crie um <literal>link</literal> simbólico para ele.
|
|
(Isso precisa ser resolvido.)
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um <literal>link</literal> para o diretório acima
|
|
para o servidor web:</para>
|
|
|
|
<screen>ln -s /dumpster/pointyhat/<replaceable>arch</replaceable>/archive archive</screen>
|
|
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>Os próximos passos são mais fáceis de serem realizados
|
|
como o usuário
|
|
<literal>ports-<replaceable>arch</replaceable></literal>.</para>
|
|
</note>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>No diretório
|
|
<filename>/var/portbuild/<replaceable>arch</replaceable></filename>
|
|
execute:</para>
|
|
<screen>mkdir clients</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Popule o diretório <filename>clients</filename> como de costume.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<screen>mkdir loads</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<screen>mkdir lockfiles</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um <filename>make.conf</filename> local. Nos casos
|
|
mais comuns você pode executar:</para>
|
|
|
|
<screen>ln ../make.conf ./make.conf</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um arquivo vazio <filename>mlist</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base) Crie o
|
|
<filename>pnohang.<replaceable>arch</replaceable></filename>.
|
|
(O modo mais fácil é fazer isso em um cliente,
|
|
e depois copiar o arquivo de volta):</para>
|
|
|
|
<screen>cc pnohang.c -o pnohang-<replaceable>arch</replaceable></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie um novo arquivo <filename>portbuild.conf</filename>
|
|
a partir de um existente para uma outra arquitetura.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie os arquivos
|
|
<filename>portbuild.<replaceable>machinename</replaceable>.conf</filename>
|
|
personalizando-os de forma adequada.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><screen>cd .ssh && ssh-keygen</screen></para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Edite o arquivo <filename>.ssh/config</filename> para
|
|
tornar mais conveniênte o uso do
|
|
<application>ssh</application>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie o diretório de configuração privada:</para>
|
|
|
|
<screen>mkdir /var/portbuild/conf/<replaceable>arch</replaceable></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Crie os <literal>scripts</literal>
|
|
<filename>dotunnel.*</filename> que forem necessários
|
|
dentro do diretorio acima.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>Mais uma vez usando
|
|
<application>sudo</application>:</para>
|
|
</note>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Informe o <application>qmanager</application> sobre a
|
|
arquitetura:</para>
|
|
|
|
<screen>python <replaceable>path</replaceable>/qmanager/qclient add_acl name=ports-<replaceable>arch</replaceable> uidlist=ports-<replaceable>arch</replaceable> gidlist=portmgr sense=1</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o novo código base):
|
|
Adicione a <replaceable>arch</replaceable> na variável
|
|
<makevar>SUPPORTED_ARCHS</makevar> do arquivo
|
|
<filename>/var/portbuild/<replaceable>arch</replaceable>/server.conf</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Edite o
|
|
<filename>/var/portbuild/scripts/buildenv</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Adicione o diretório <replaceable>arch</replaceable> no
|
|
<filename>/var/portbuild/scripts/zbackup</filename> e no
|
|
<filename>/var/portbuild/scripts/zexpire</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Necessário apenas para o antigo código base): Como no
|
|
procedimento para criação de um novo
|
|
<literal>branch</literal>: crie os <literal>links</literal>
|
|
para o servidor web no diretório
|
|
<filename>/var/portbuild/errorlogs/</filename>:</para>
|
|
|
|
<screen>ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/bak/errors <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-full
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/bak/logs <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-full-logs
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/errors <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-latest
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/logs <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-latest-logs
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/bak/packages <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-packages-full
|
|
ln -s ../<replaceable>arch</replaceable>/<replaceable>branch</replaceable>/builds/latest/packages <replaceable>arch</replaceable>-<replaceable>branch</replaceable>-packages-latest</screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Crie mais dois <literal>links</literal> simbólicos para o
|
|
servidor web dentro do diretório
|
|
<filename>/var/portbuild/errorlogs/</filename>:</para>
|
|
|
|
<screen>ln -s ../<replaceable>arch</replaceable>/archive/buildlogs <replaceable>arch</replaceable>-buildlogs
|
|
ln -s ../<replaceable>arch</replaceable>/archive/errorlogs <replaceable>arch</replaceable>-errorlogs</screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>Novamente como
|
|
<literal>ports-<replaceable>arch</replaceable></literal>:</para>
|
|
</note>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Para cada <literal>branch</literal> que será suportado,
|
|
faça o seguinte:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Inicie a compilação para o <literal>branch</literal>
|
|
com:</para>
|
|
|
|
<screen>build create <replaceable>arch</replaceable> <replaceable>branch</replaceable></screen>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para><link linkend="setup">Crie o
|
|
<filename>bindist.tar</filename></link>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<note>
|
|
<para>Uma última vez usando o
|
|
<application>sudo</application>:</para>
|
|
</note>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>(Necessário apenas para o antigo código base): Só depois
|
|
que a primeira execução do
|
|
<application>dopackages</application> for feita para a
|
|
arquitetura: adicione a arquitetura ao
|
|
<filename>/var/portbuild/scripts/dopackagestats</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Adicione uma entrada <replaceable>arch</replaceable>
|
|
apropriada para o
|
|
<filename>/var/portbuild/scripts/dologs</filename> no
|
|
<filename>crontab</filename> do usuário root. (Esta é uma
|
|
solução paliativa)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect1>
|
|
|
|
<sect1 id="new-head-node">
|
|
<title>Como configurar um novo nó principal (instância do
|
|
pointyhat)</title>
|
|
|
|
<para>Esta seção está em progresso.</para>
|
|
|
|
<para>Por favor, consulte o Mark Linimon antes de efetuar qualquer
|
|
mudança.</para>
|
|
|
|
<sect2 id="pointyhat-basics">
|
|
<title>Instalação básica</title>
|
|
|
|
<procedure>
|
|
|
|
<step>
|
|
<para>Instale o &os;.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Para cada arquitetura suportada, adicione um usuário e
|
|
grupo
|
|
<literal>ports-<replaceable>${arch}</replaceable></literal>.
|
|
Adicione os usuários ao grupo <literal>wheel</literal>.
|
|
Eles devem ter um <literal>'*'</literal> como senha.
|
|
Crie também, de modo similar, o usuário
|
|
<literal>ports</literal> e
|
|
<literal>portmgr</literal>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Para cada arquitetura suportada, crie o
|
|
<filename>/home/ports-<replaceable>${arch}/.ssh/</replaceable></filename>
|
|
e popule o <filename>authorized_keys</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Crie os arquivos apropriados em
|
|
<filename>/etc/.ssh/</filename>.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Adicione a seguinte linha ao arquivo
|
|
<filename>/boot/loader.conf</filename>:</para>
|
|
|
|
<screen>console="vidconsole,comconsole"</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Adicione as seguintes linhas ao arquivo
|
|
<filename>/etc/sysctl.conf</filename>:</para>
|
|
|
|
<screen>kern.maxfiles=40000
|
|
kern.maxfilesperproc=38000</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Certifique-se de que as seguintes mudanças foram
|
|
realizadas no <filename>/etc/ttys</filename>:</para>
|
|
|
|
<screen>ttyu0 "/usr/libexec/getty std.9600" vt100 on secure</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Ainda a ser definido.</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="pointyhat-disk">
|
|
<title>Configurando o disco</title>
|
|
|
|
<procedure>
|
|
|
|
<step>
|
|
<para>Crie um volume <application>zfs</application> chamado
|
|
<filename>a</filename> e monte-o em
|
|
<filename>/a</filename>:</para>
|
|
|
|
<screen># zpool create a mirror da1 da2 mirror da3 da4 mirror da5 da6 mirror da7 da8</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Configure o diretório base do
|
|
<literal>portbuild</literal>:</para>
|
|
|
|
<screen># mkdir -p /a/portbuild
|
|
# cd /a/portbuild
|
|
# chown portmgr:portmgr .
|
|
# chmod 775 .</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Ainda a ser definido.</para>
|
|
</step>
|
|
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="pointyhat-src">
|
|
<title>Configurando o <literal>src</literal></title>
|
|
|
|
<procedure>
|
|
|
|
<step>
|
|
<para>Ainda a ser definido.</para>
|
|
</step>
|
|
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="pointyhat-ports">
|
|
<title>Configurando o <literal>ports</literal></title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Os seguintes <literal>ports</literal> (ou seus
|
|
sucessores mais recentes) são obrigatórios:</para>
|
|
|
|
<screen>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)</screen>
|
|
|
|
<para>Os ports acima também irão instalar:</para>
|
|
|
|
<screen>databases/sqlite3
|
|
lang/perl-5.12
|
|
lang/python27</screen>
|
|
|
|
<para>Os seguintes <literal>ports</literal> (ou seus
|
|
sucessores mais recentes) são fortemente
|
|
recomendados:</para>
|
|
|
|
<screen>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</screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Configure o e-mail fazendo o seguinte: (ainda a ser
|
|
definido).
|
|
</para>
|
|
</step>
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="pointyhat-other">
|
|
<title>Outros</title>
|
|
|
|
<procedure>
|
|
|
|
<step>
|
|
<para>Ainda a ser definido.</para>
|
|
</step>
|
|
|
|
</procedure>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="disk-failure">
|
|
<title>Procedimentos para lidar com falhas de disco</title>
|
|
|
|
<para>Quando uma máquina tem uma falha de disco (por exemplo,
|
|
um <literal>panic </literal> devido a erros de leitura, etc.),
|
|
devemos executar os seguintes procedimentos:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem><para>Anote o tempo e o tipo de falha
|
|
(por exemplo, colea saída do console que for relevante) no
|
|
<filename>/var/portbuild/<replaceable>${arch}</replaceable>/reboots</filename></para></listitem>
|
|
|
|
<listitem><para>Para os clientes gohan i386, limpe o disco
|
|
criando o arquivo <filename>/SCRUB</filename> no
|
|
<literal>nfsroot</literal> (por exemplo,
|
|
<filename>/a/nfs/8.dir1/SCRUB</filename>) e reinicie. Isso
|
|
vai executar um <command>dd if=/dev/zero of=/dev/ad0</command>
|
|
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.</para>
|
|
|
|
<note><para>Para os sistemas <literal>blade</literal> i386,
|
|
outro sinal de falha nos discos é quando a
|
|
<literal>blade</literal> fica em espera e não responde a
|
|
qualquer comando pelo console, ou mesmo pelo
|
|
NMI.</para></note>
|
|
|
|
<para>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.</para></listitem>
|
|
|
|
<listitem><para>Se o problema persistir, então provavelmente o
|
|
disco está inutilizado. Remova a máquina do
|
|
<filename>mlist</filename> e (para discos ATA) execute o
|
|
<command>smartctl</command> na unidade:</para>
|
|
|
|
<screen>smartctl -t long /dev/ad0</screen>
|
|
|
|
<para>Isso vai levar cerca de 30 minutos:</para>
|
|
|
|
<screen>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.</screen>
|
|
|
|
<para>Quando o comando acima finalizar, execute o comando
|
|
<command>smartctl -a /dev/ad0</command> para verificar o
|
|
estado da unidade:</para>
|
|
|
|
<screen># 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</screen>
|
|
|
|
<para>Ele também exibirá outros dados, incluindo um
|
|
<literal>log</literal> dos erros anteriores da unidade. É
|
|
possível que a unidade mostre erros de
|
|
<acronym>DMA</acronym> embora não apresente falhas no
|
|
auto-teste (por conta do remapeamento de
|
|
setores).</para></listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Quando um disco falhar, por favor, informe os
|
|
administradores do <literal>cluster</literal>, para que possamos
|
|
substituí-lo.</para>
|
|
</sect1>
|
|
</article>
|