HowtoPMC Ps

B
eowulf e o
a i
Como Construir e Operar o Seu Pr

oprio
Sistema PMC de Pro essamento Paralelo
Baseado no Sistema Opera ional Linux
Ah, sim, quase ia esque endo:
aqui na terra dos Sa is!

Jorge L. deLyra
Depto. de F
si a Matem
ati a
Instituto de F
si a
Universidade de S~
ao Paulo
Fevereiro de 2001
Vers~ao 0.3
Resumo
E apresentada uma orienta ~ao te ni a, nan eira e estrategi a bastante ompleta para
a montagem, instala ~ao e opera ~ao de um sistema de pro essamento paralelo de alto
desempenho. Assume-se que o ambiente onde isto o orre seja uma institui ~ao, tipi amente de ensino e pesquisa, lo alizada neste pas. O sistema no qual o autor esta mais
diretamente envolvido e usado omo exemplo e des rito em detalhe.
A apli abilidade da arquitetura apresentada e muito ampla e exvel. Trata-se de
um sistema om desempenho extremamente alto para ns de al ulo numeri o, que
pode ser obtido por pre os muito modestos. O sistema e altamente es alavel, om
desempenho total aproximadamente propor ional ao investimento feito. O esquema
proposto tambem leva em onta os aspe tos de fa ilidade de opera ~ao e manuten ~ao,
bem omo uma losoa de ompartilhamento de re ursos omputa ionais de al ulo.
Apesar de que este do umento trata espe i amente da montagem e instala ~ao de
um luster de pro essamento paralelo de alto desempenho, varios dos omponentes e
elementos envolvidos s~ao apli aveis a montagem e instala ~ao de servidores de uso geral para departamentos e grupos de pesquisa, bem omo a montagem e instala ~ao de
terminais gra os para uso individual em uma rede lo al de uso geral.
Assim, este do umento podera ser util tambem para pessoas e grupos que estejam
envolvidos em suprir suas ne essidades basi as relativas a informati a ontemporânea.
Tambem e possvel integrar o atendimento as ne essidades de arater geral om a satisfa ~ao das ne essidades mais espe as de al ulo numeri o. Ao nal do do umento s~ao
dadas algumas sugest~oes e apontadas algumas possibilidades neste sentido.
Copyright 2001 by Jorge L. deLyra

Este do umento, in luindo todas as se ~oes, textos, programas, arquivos de dados, guras e demais partes que o omp~oem, e distribudo nos termos da "General Publi
Li ense" uja ntegra pode ser en ontrada no arquivo GPL dentro do sub-diretorio do /
do diretorio-raiz da arvore de ompila ~ao do do umento. Alem disso, uma trans ri ~ao
da vers~ao original ompleta desta li en a pode ser en ontrada no apêndi e H.
S~ao permitidas a opia e distribui ~ao livres deste do umento nos termos daquela
li en a. Caso sejam feitas mudan as no do umento, a distribui ~ao da vers~ao modi ada
so pode ser feita se for in luda nela um aviso laro e bem visvel de que o do umento
foi modi ado, om a data. A vers~ao original deste do umento pode ser en ontrada na
teia mundial (\World Wide Web") e obtida atraves da rede, no endere o (URL):
http://latt.if.usp.br/pm /
This do ument, in luding all se tions, texts, programs, data les, gures and and any
others of its omponent, is distributed under the terms of the "General Publi Li ense",
the integral text of whi h may be found in the le GPL in the subdire tory do / of the
root dire tory of the do ument's ompilation tree. Besides, a full trans ription of the
original version of the li ense may be found in appendix H.
The opy and distribution of this do ument are permitted under the terms of that
li ense. In ase hanges are made to the do ument, the modied version an be distribution only if it in ludes a lear and visible noti e stating that the do ument was
modied, with the date. The original version of this do ument may be found in the
\World Wide Web" and obtained through the network, at the URL:
Sumario
1 Preliminares
1.1
1.2
1.3
1.4
1.5
Avalia ~ao da Situa ~ao . . . . . . . . .

Proposta deste Do umento . . . . . . .
Quali a ~oes e Limita ~oes do Autor . .
Quali a ~oes e Limita ~oes do Leitor . .
Estrategia de Leitura deste Do umento
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Des ri ~ao Geral da Solu ~ao Proposta . . .

Fun ~ao de ada Componente do PMC . . .
Des ri ~ao Detalhada dos Componentes . .
Des ri ~ao do Pro esso de Montagem . . .
2.4.1 Montagem da Motherboard . . . .
2.4.2 Montagem das Pe as no Gabinete .
2.4.3 Conex~oes ao Gabinete e Opera ~ao .
Detalhes da Montagem do Front-End . . .
Detalhes da Montagem do Servidor . . . .
Detalhes da Montagem do Terminal . . . .
Detalhes da Montagem dos Nos . . . . . .
Montagem do Equipamento de Rede . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2 Hardware
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
3 Software
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Como o Sistema todo Opera . . . . . . .

Papel de ada Elemento de Software . .
Pro edimento Geral de Instala ~ao . . . .
Pro edimento de Compila ~ao do Kernel .
Detalhes da Instala ~ao do Front-End . .
Detalhes da Instala ~ao do Servidor . . .
Detalhes da Instala ~ao do Terminal . . .
Detalhes da Instala ~ao dos Nos . . . . .
Detalhes da Instala ~ao da Rede . . . . .
i
.
.
.
.
.
.
.
.
.
1
2
3
4
5
7
8
10
12
12
13
14
15
16
17
18
21
23
23
25
26
29
32
33
35
37
40
ii

SUMARIO
4 Opera ~ao
4.1 Uso do Sistema pelos Usuarios . . . . . . . .

4.2 Geren iamento e Administra ~ao . . . . . . .
4.2.1 Rotinas Administrativas . . . . . . .
4.2.2 Instala ~ao de Novos Nos . . . . . . .
4.2.3 Monitoramento dos Nos . . . . . . .
4.2.4 Problemas om um dos Nos . . . . .
4.3 Upgrades de Sistema . . . . . . . . . . . . .
4.3.1 Upgrade do Kernel . . . . . . . . . .
4.3.2 Upgrade da Debian . . . . . . . . . .
4.3.3 Comentarios sobre ada Componente
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5.1 Algumas Pondera ~oes e Justi ativas . . . . . .

5.1.1 Pe as e n~ao Maquinas Prontas . . . . . .
5.1.2 Arquitetura Intel e n~ao Alpha . . . . . .
5.2 Preo upa ~oes om a Infra-Estrutura . . . . . . .
5.2.1 Metodo de Alimenta ~ao de For a . . . .
5.2.2 Temperatura e Refrigera ~ao . . . . . . .
5.3 Perspe tivas de Desenvolvimento Futuro . . . .
5.3.1 Possibilidades de Expans~ao do Cluster .
5.3.2 Possveis Desenvolvimentos Te nologi os
5.4 Sobre a Utiliza ~ao dos Re ursos . . . . . . . . .
5.4.1 Novo Paradigma de Programa ~ao . . . .
5.4.2 Filosoa de Uso e Compartilhamento . .
5.5 Outras Apli a ~oes das Mesmas Ideias . . . . . .
5.6 Variadas Alternativas Possveis . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Comentarios
A Problemas
A.1
A.2
A.3
A.4
Transi ~ao dos Servidores de NFS . .

Uso de Pla as de Rede 3C905B/C . .
Aquisi ~ao de um Gravador de Eprom
Sobre a Qualidade do Hardware . . .
B Or amentos
B.1
B.2
B.3
B.4
B.5
B.6
B.7
Front-End . . . . . . .
Servidor . . . . . . . .
Terminal . . . . . . . .
No . . . . . . . . . . .
Equipamento de Rede
No-breaks . . . . . . .
Condi ionadores de Ar
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
44
45
46
46
47
48
48
49
50
52
52
52
53
55
55
56
58
58
60
63
63
65
67
68
70
70
71
73
75
78
79
79
80
81
81
82
82
iii

SUMARIO
B.8 Estante para Montagem dos Nos . . . . . . . . . . . . . . . . . . . . . . . 82

B.9 Materiais Auxiliares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
C Congura ~ao
C.1 Bibliote a de Arquivos de Congura ~ao .

C.1.1 Front-End . . . . . . . . . . . . .
C.1.2 Servidor . . . . . . . . . . . . . .
C.1.3 Terminal . . . . . . . . . . . . . .
C.1.4 Nos . . . . . . . . . . . . . . . . .
C.1.5 Usuario . . . . . . . . . . . . . .
C.2 Bibliote a de S ripts . . . . . . . . . . .
C.3 Outros Arquivos e Listas . . . . . . . . .
C.4 Bibliote a de Diagramas . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D.1 Re eitas de Montagem de Hardware . . . . . . . . . . .

D.1.1 Ferramentas e Materiais Ne essarios . . . . . . .
D.1.2 Congura ~ao Geral do Bios . . . . . . . . . . .
D.1.3 Congura ~oes Espe as de Cada Componente
D.2 Re eitas de Instala ~ao de Software . . . . . . . . . . .
D.2.1 Instala ~ao de um Espelho Lo al . . . . . . . . .
D.2.2 Roteiro de Compila ~ao do Kernel dos Nos . . .
D.2.3 Roteiro de Compila ~ao do Etherboot . . . . . .
D.3 Re eitas de Opera ~ao . . . . . . . . . . . . . . . . . . .
D.3.1 Como usar o onsole serial . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
D Re eitas
E Imagens
E.1
E.2
E.3
E.4
E.5
E.6
Parti ionamento dos Dis os . . . . . .

Uso do Console Serial dos Nos . . . . .
Congura ~ao do Kernel do Front-End .
Congura ~ao do Kernel do Servidor . .
Congura ~ao do Kernel do Terminal .
Congura ~ao do Kernel de um No . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
84
85
88
91
93
96
96
99
101
103
103
103
105
111
114
114
116
120
122
122
125
125
126
126
130
133
137
F In ompletudes
141
G Glossario
143
H Li en a
148
iv

SUMARIO
Agrade imentos
O autor gostaria de agrade er as seguintes pessoas, todos te ni os, analistas, programadores, administradores, alunos, ex-alunos de gradua ~ao ou de pos-gradua ~ao deste
Instituto, na maior parte dos asos mais de uma destas oisas, que o ajudaram em
variados aspe tos desta interessante aventura te nologi a, deste aspe tos te ni os de
hardware e software ate aspe tos nan eiros e de programa ~ao ient a:
Arnaldo Gomes de Oliveira Filho
Fabio de Oliveira Jorge
Fran is o Dellatorre Borges
Jo~ao Luis Meloni Assirati
Luiz Blanes
Paulo Nakati
Roberto Conti
Captulo 1
Preliminares
1.1 Avalia ~ao da Situa ~ao
Neste in io de um novo milênio e impossvel enfatizar em ex esso a importân ia da
omputa ~ao para a iên ia, em espe ial a omputa ~ao de alto desempenho. Estamos
em meio a uma profunda revolu ~ao que envolve de forma essen ial a te nologia da
informa ~ao. Computadores ada vez mais rapidos e poderosos est~ao ada vez mais
a essveis, em parti ular para as atividades da iên ia, n~ao so para grandes institui ~oes
mas tambem para ada pesquisador individual, dando ao indivduo e a pequenos grupos
de pesquisa apa idades e autonomia que seriam inimaginaveis mesmo ha alguns pou os
anos. Desta forma, a iên ia passa a usufruir dos frutos da grande e fundamental
revolu ~ao ient a do primeiro quarto do se ulo XX, que testemunhou o surgimento
da me âni a quânti a. Desta forma, a moderna te nologia da informa ~ao transforma-se
agora num dos prin ipais instrumentos para permitir o progresso da propria iên ia.
A omputa ~ao, em espe ial aquela utilizada para al ulos numeri os e de outros
tipos om desempenho extremamente alto, tem hoje um papel muito importante em
todas as areas da iên ia, sendo que em muitas delas este papel e fundamental e ru ial
para o seu desenvolvimento. N~ao se trata aqui apenas da fsi a e de outras iên ias
que tradi ionalmente fazer uso deste tipo de pro essamento, mas de todas as areas da
iên ia. Um exemplo de uma area onde o uso de sistemas de pro essamento intensivo
esta em pleno ores imento e a biologia mole ular, para a analise das sequên ias de
bases de DNA em genomas. Fi a laro que a importân ia da informati a para a iên ia
tende a aumentar ada vez mais no futuro. Assim, uma infra-estrutura omputa ional
solida, que supra tanto as ne essidades de omuni a ~ao quanto as de armazenamento e
manipula ~ao de informa ~ao, e hoje e sera ada vez mais no futuro um insumo essen ial
para viabilizar as atividades de qualquer grupo de pesquisa.
Um dos aspe tos mais re entes e profundos da revolu ~ao da informati a e o que se
onven ionou hamar de revolu ~ao do free software. Apesar de que as ideias e o movimento de free software ja existem ha algum tempo, neste momento ele esta explodindo
1
CAPITULO 1. PRELIMINARES
em todo o mundo, atalisado e apitaneado pelo enorme su esso do primeiro sistema

opera ional om open sour e, o Linux. A ombina ~ao do sistema opera ional Linux
om inumeros outros elementos de free software e om os modernos mi ro-pro essadores
de alto desempenho e baixo usto possibilita que mesmo grupos de pesquisa muito pequenos e om pou os re ursos possuam sistemas omputa ionais om poder de al ulo
signi ativo. Esta ombina ~ao permite tambem que estes mesmos grupos montem, instalem e geren iem os seus proprios sistemas, tanto aqueles de uso geral quanto aqueles
dedi ados a pro essamento intensivo.
1.2 Proposta deste Do umento

Este do umento e um guia detalhado para a montagem e instala ~ao de um PMC, um
sistema de pro essamento numeri o paralelo altamente es alavel, baseado em mi ro omputadores, de baixo usto e de fa il manuten ~ao e geren iamento. Imagina-se que o
sistema va ser montado ompletamente, a partir de pe as, pelos proprios membros dos
grupos de pesquisa que ir~ao utilizar o equipamento. Ao ontrario do que pare e pensar a
maior parte das pessoas, a montagem de hardware de um omputador ontemporâneo e
uma opera ~ao bastante simples e segura. A instala ~ao e opera ~ao do sistema opera ional
e um pou o mais omplexa e requer mais onhe imento, mas pode perfeitamente ser
realizada pelos membros de um grupo de pesquisa, em parti ular pelos mais jovens, que
em geral ja têm uma maior empatia om os assuntos da informati a.
Foi-se o tempo em que o a esso a omputadores extremamente rapidos estava limitado a uns pou os pesquisadores om a esso a re ursos ex ep ionais. Foi-se o tempo
em que a melhor solu ~ao era adquirir um sistema pronto, empa otado e fe hado de
um forne edor, por altos pre os de instala ~ao e manuten ~ao, riando serios problemas
de dependên ia em rela ~ao a este forne edor. A atual revolu ~ao na industria da informati a representa um tremendo \empowerment" do indivduo e uma demo ratiza ~ao
muito benvinda dos meios de se fazer iên ia. Os sistemas est~ao ada vez mais abertos
e mais livres e, om esta liberdade, vem tambem a responsabilidade de ada grupo e de
ada pesquisador pelos seus proprios meios de trabalho. E ne essario que os pesquisadores passem por um pro esso de aprendizado que os permita montar e operar os novos
e poderosos equipamentos. Entretanto, devido a revolu ~ao do free software, este treinamento n~ao e muito diferente do treinamento que seria ne essario de qualquer forma,
simplesmente para permitir aos pesquisadores o simples uso geral dos equipamentos.
Para que possa ser detalhado e ompleto, este do umento apresenta um aso on reto
omo exemplo, o prototipo de 6 nos que esta sendo onstrudo pelo autor e seu pequeno
grupo de pesquisa. Entretanto, o esquema utilizado e exvel e adaptavel a um amplo
espe tro de situa ~oes. Por simpli idade, em vez de ome ar denindo detalhadamente
o problema que este projeto pretende resolver para depois delinear a solu ~ao, vamos
partir de uma des ri ~ao detalhada da nossa solu ~ao e omentar sobre suas apa idades
e possveis modi a ~oes e alternativas. Varios aspe tos in uen iaram as es olhas feitas,
~
~
1.3. QUALIFICAC
OES
E LIMITAC
OES
DO AUTOR
tanto da arquitetura omo um todo quanto de ada pe a de hardware em parti ular.
Para itar alguns: as limita ~oes de verbas; a provavel ausên ia de um analista dedi ado a uidar do sistema; a grande fragilidade de nossos sistemas de alimenta ~ao de
for a; a ne essidade ou n~ao de ondi ionamento de ar; a ne essidade de simpli idade na
montagem; o uso ex lusivo de software open sour e obtenvel livremente na Internet.
1.3 Quali a o~es e Limita o~es do Autor

Depois de um urso de gradua ~ao em fsi a durante o qual o que se fazia de omputa ~ao
era apenas algum al ulo numeri o a ompanhado de alguns pou os exer ios de programa ~ao realizados em um omputador main-frame atraves de art~oes perfurados, o autor
foi ini iado na informati a moderna, durante as suas atividades de doutoramento, em
sistemas VAX-VMS. Seu primeiro ontato om o Unix foi atraves da migra ~ao para uma
vers~ao deste sistema opera ional dos super- omputadores vetoriais Cray que se usava
na epo a para pro essamento numeri o intensivo. A transi ~ao ompleta para o Unix so
a onte eu depois da sua volta ao pas, a partir de 1990, quando ele ja tinha 36 anos.
A transi ~ao para o Linux foi ainda mais re ente, tendo ome ado quatro ou in o anos
depois disto. Assim, o treinamento do autor nos sistemas omputa ionais modernos
foi tardia e, alem disso, foi feita de forma ompletamente autônoma, atraves de muita
tentativa e erro, dada a total ausên ia de uma ultura Unix no pas.
Durante os mais de dez anos durante os quais esteve sempre lidando om estes novos
sistemas, o autor adquiriu grande experiên ia om eles, tendo mesmo se tornado num
espe ialista no seu uso em ambientes a adêmi os de ensino e pesquisa. Ele on ebeu,
esteve envolvido na obten ~ao, montou, instalou e, durante muito tempo, geren iou os
seguintes sistemas da Universidade de S~ao Paulo: o sistema omputa ional de pesquisa
do Departamento de Fsi a Matemati a, in luindo varias gera ~oes de sistemas de pro essamento numeri o intensivo; o sistema omputa ional didati o do Curso de Ciên ias
Mole ulares; os sistemas omputa ionais didati os do Projeto So rates do Instituto de
Fsi a. Alem disso, ele esteve envolvido de forma profunda om a on ep ~ao e instala ~ao
da moderna rede USPnet da Universidade de S~ao Paulo, bem omo do Laboratorio de
Computa ~ao Cient a Avan ada, entre varias outras oisas, durante sua parti ipa ~ao
na gest~ao Fava.
Em suma, o que se reporta neste do umento s~ao resultados de experiên ia direta
obtida durante muitos anos de atividade na area. Por outro lado, deve ser enfatizado
aqui que estamos passando por uma revolu ~ao nesta area, o que signi a que a situa ~ao
muda om frequên ia e, muitas vezes, de forma drasti a. Manter-se atualizado nesta
area requer um exer io onstante de exibilidade, revis~ao e adapta ~ao, que e frequentemente dif il e que as vezes pode ser doloroso. Assim, toda a informa ~ao te ni a objetiva
e detalhada que se en ontra neste do umento deve ser avaliada no ontexto da data de
es rita do mesmo. Em seis meses ou menos a situa ~ao pode ter mudado signi ativamente, tornando muitos dos detalhes obsoletos. Entretanto, reio que as estrategias
gerais apresentadas, bem omo as losoas de uso e de implementa ~ao dos sistemas que
s~ao adotadas aqui, sejam validas em prazos bem mais longos do que este.
Uma oisa que deve ser dita laramente e que o autor n~ao e usuario nem profundo
onhe edor dos sistemas PVM e MPI de passagem de mensagens. O motivo disto e
que o tipo de pro essamento em que esta envolvido em suas atividades de pesquisa,
simula ~oes de Monte Carlo de sistemas em redes dis retas, pres inde da utiliza ~ao deste
tipo de programa ~ao. E muito simples paralelizar programas de simula ~ao esto asti a,
basta fazer varias simula ~oes estatisti amente independentes e simplesmente juntar as
amostragens estatsti as obtidas pelas diversas simula ~oes. Como n~ao ha ne essidade
de sin roniza ~ao das estruturas de dados em nenhum momento, n~ao ha ne essidade de
uso de message passing. Devido a isto, nada mais sera dito sobre PVM e MPI nestas
notas. Entretanto, deve-se observar que estas bibliote as ja est~ao de fato disponveis
para o tipo de sistema que vamos des rever aqui. De fato, temos planos de utiliza-las
no futuro e estamos, neste momento, tentando nossas primeiras experiên ias om elas.
1.4 Quali a o~es e Limita o~es do Leitor

Espera-se, para que a leitura deste do umento seja frutfera, que o leitor ja seja um
usuario de sistemas Unix ou Linux, pois n~ao se pretende aqui promover um treinamento
de usuarios a partir do zero. Por outro lado, n~ao e ne essario que o leitor seja um
analista de sistemas no sentido tradi ional, nem tampou o um ha ker de free software.
De fato, n~ao se prevê de todo a parti ipa ~ao de prossionais no estilo tradi ional desta
area na montagem, opera ~ao e geren iamento do sistema que sera onstrudo. Todo o
trabalho de montagem, opera ~ao e geren iamento deve ser feito pelos proprios usuarios
do sistema. Trata-se de um projeto do tipo \do-it-yourself" ou, para olo ar de forma
mais pre isa, \keep-doing-it-yourself".
Espera-se que o leitor e os grupos de pesquisa que ir~ao utilizar o equipamento ja
disponham de sistemas omputa ionais Unix ou Linux de uso geral em suas redes lo ais.
Imagina-se que os sistemas ja existentes na rede lo al provenham os servi os basi os
de uma rede lo al e da Internet omo, por exemplo, servi os de dis o para home dos
usuarios. Caso o leitor nun a tenha instalado um sistema Linux, re omenda-se que
passe primeiro pela experiên ia de fazer isto om a distribui ~ao Debian em algum mi ro omputador de sua rede lo al, antes de tentar a instala ~ao do sistema no PMC. Para um
urso prati o e objetivo de uso (mas n~ao da instala ~ao) do sistema opera ional Linux,
re omenda-se a leitura das apostilas que podem ser en ontradas no endere o
http://latt.if.usp.br/fma215/apostilas/
bem omo a exe u ~ao em um mi ro- omputador om Linux das sequên ias de tarefas
que se en ontra nelas. Estas apostilas obrem de forma ampla e geral os fundamentos
do uso do sistema, mas n~ao abordam de todo as quest~oes de instala ~ao e geren iamento

1.5. ESTRATEGIA
DE LEITURA DESTE DOCUMENTO
do sistema. Para se informar subsequentemente sobre os pro edimentos de instala ~ao o

leitor deve utilizar a do umenta ~ao de instala ~ao da distribui ~ao Debian, que e bastante
ompleta e pode ser en ontrada em formato HTML, legvel atraves de um browser, no
diretorio
debian/dists/stable/main/disks-i386/ urrent/do /
em qualquer espelho da distribui ~ao. O link para o site original e

http://ftp.debian.org/debian/dists/stable/main/disks-i386/ urrent/do /
Mas, mais do que isto, a Debian tem apoio para do umenta ~ao em varias lnguas e uma
boa parte da do umenta ~ao ja existe em português! Neste momento nem tudo ja esta
traduzido, mas ha um onjunto ompleto de do umenta ~ao par ialmente traduzida no
sub-diretorio pt/. Entretanto, ainda pode ser ne essario a essar ada um dos arquivos
individualmente pois neste momento a arvore de referên ias de HTML ainda n~ao esta
pronta. Para fa ilidade de a esso, mantemos links para estes diretorios na home page
do PMC:
http://latt.if.usp.br/pm /debian/
http://latt.if.usp.br/pm /debian pt.html
Em suma, n~ao se espera do leitor e de seu grupo de pesquisa nenhum tipo de \expertise" te ni a em informati a, mas apenas que pelo menos alguns deles sejam usuarios
ja relativamente autônomos de sistemas Unix ou Linux. Espera-se tambem que estejam
dispostos a aprender oisas novas e a enfrentar desaos te ni os omo parte de suas
atividades ient as.
1.5 Estrategia de Leitura deste Do umento

Os aptulos que seguem apresentam os aspe tos de montagem de hardware, instala ~ao
de software e de opera ~ao do sistema. Ao nal ha um aptulo ontendo omentarios
variados sobre a arquitetura proposta, estrategias de opera ~ao, losoa de uso e assim
por diante. A abordagem pretende ser razoavelmente detalhada e ompleta em ada um
dos aptulos, mas as tabelas e re eitas mais espe as se en ontram em apêndi es. Ha
tambem um apêndi e sobre alguns problemas que n~ao est~ao ompletamente resolvidos
neste momento.
Dependendo do nvel de sua experiên ia anterior om as te nologias de hardware
e software que est~ao envolvidas uma leitura ompleta do do umento pode ou n~ao ser
ne essaria. Se vo ê for um usuario ainda relativamente inexperiente, re omendamos
uma leitura preliminar ompleta de todo o do umento. Alem disso, e uma boa ideia ter
uma opia dele sempre disponvel para referên ia durante todo o trans orrer do projeto.
Se vo ê ja for um usuario bem experiente e ja teve experiên ia anterior om a montagem
do hardware, deve bastar dar uma boa olhada nas guras e tabelas do texto seguida de
um uso imediato ou na adapta ~ao as suas ne essidades das tabelas e re eitas ontidas
nos apêndi es.
Este do umento e mantido na rede WWW em uma vers~ao HTML, na qual todos os
hyperlinks de HTML que apare em ao longo dele s~ao ativos. Desta forma e possvel n~ao
so ter a esso direto a muitas fontes de do umenta ~ao omo e possvel obter para uso
em seu PMC arquivos de ongura ~ao, s ripts de shell para realizar tarefas espe as,
listas e outras oisas. Alem disso, a vers~ao que esta na rede e ertamente a mais atual.
Vo ê tambem pode obter na rede este do umento em formato PS, para impress~ao em
papel. O site onde todo este material e mantido e o home site do PMC, onde esta a sua
home page. No momento este site esta hospedado no endere o
mas e provavel que isto venha eventualmente a mudar. Ate que haja alguma mudan a, em todo link ontido neste do umento que n~ao ontenha as partes relativas
ao proto olo e ao endere o do servidor deve-se entender que o endere o a in luir e
http://latt.if.usp.br/.
Observe-se que vamos usar livremente termos te ni os em Inglês omo parte do texto
deste do umento, sem envovê-los em haspas omo mandam os ânones da nossa lngua.
Estes termos s~ao usados om grande frequên ia e muitos deles ja foram, na prati a,
in orporados a lingua, apesar dos veementes protestos de A adamias e outros org~aos
o iais, o iosos e populares. O uso de haspas para estes termos apenas ontribuiria
para tornar o texto signi ativamente menos legvel e sera reservado apenas para dar
ênfase a introdu ~ao de novos termos e on eitos ao longo do do umento. Tambem vamos
usar livremente termos te ni os e siglas, omo e habitual nesta area. Ha no apêndi e G
um glossario que dene todas as siglas e termos te ni os que s~ao usadas no texto.
Captulo 2
Hardware
A montagem do hardware e a parte mais fa il do projeto. A maior di uldade aqui e
es olher o tipo e velo idade do CPU a utilizar, de forma a otimizar a rela ~ao desempenho/ usto do resultado nal. Esta de is~ao depende de varios fatores, alguns deles
ir unstan iais, podendo mudar om o tempo. Vamos des rever aqui aquela que a reditamos ser a melhor solu ~ao neste momento. A arquitetura geral da solu ~ao es olhida e
uma solu ~ao que deve ser valida ainda por algum tempo, mas os detalhes podem ter de
ser ajustados em prazos relativamente urtos devido aos desenvolvimentos rapidos da
industria da informati a.
2.1 Des ri ~ao Geral da Solu ~ao Proposta

A arquitetura geral do sistema paralelo de pro essamento in lui in o elementos distintos
basi os: um front-end, que estabele e a omuni a ~ao om a Internet, um servidor de
dis o e rede, um mi ro- omputador para fun ionar omo terminal, uma rede privada e
um onjunto de nos de pro essamento. Em alguns asos e possvel juntar as fun ~oes do
front-end e do servidor de dis o em uma uni a maquina, ou mesmo juntar todas estas
fun ~oes om o servidor de home de um grupo de pesquisa, diminuindo um pou o o usto
total de um sistema de pequeno porte, veja a dis uss~ao na se ~ao 5.6. Em sua forma
basi a apresentada aqui omo exemplo, o luster pode ter ate 21 nos.
Estes elementos s~ao interligados de a ordo om o diagrama que se en ontra na gura 2.1. Neste diagrama as linhas solidas representam liga ~oes de rede atraves de abos
UTP, que e o padr~ao orrente para as liga ~oes de urta distân ia, tipi amente dentro de
um mesmo predio. A linha tra ejada representa uma liga ~ao serial, atraves da qual uma
janela no sistema X11 do terminal pode fun ionar omo onsole de boot de qualquer um
dos nos, o que pode ser muito util em aso de di uldades om algum deles. Em geral
os nos devem bootar de forma ompletamente automati a, sem nenhuma ne essidade
de interven ~ao do operador.
7
CAPITULO 2. HARDWARE
N
EQUIPAMENTO DE REDE
ASCII
N
SERVIDOR
DISCO
DOS NS
DISCO
LOCAL
TERMINAL
N
X11
ASCII
DISCOS
DISCOS
LAN
FRONTEND
CONSOLE SERIAL
Figura 2.1: Diagrama geral de blo os do PMC, mostrando os prin ipais elementos da
arquitetura.
2.2 Fun ~ao de ada Componente do PMC

Cada um dos omponentes do PMC tem uma fun ~ao espe a. Nos asos do frontend, do servidor, dos nos e do equipamento de rede esta e uma fun ~ao xa e estavel,
estas maquinas fazem apenas um tipo bem denido de oisa. Ja no aso do terminal as
fun ~oes s~ao varias e variadas.
Observe que, na ongura ~ao ompleta do PMC, todos estes omponentes s~ao distintos dos servidores de home, de rede e de servi os gerais do grupo ou dos grupos que
vierem a ser usuarios do PMC, bem omo dos mi ros que fun ionam omo terminais
para os usuarios destes grupos. Em parti ular, note que o servidor de dis o do PMC
tera dis os SCSI mas sera uma maquina distinta dos servidores de dis os de home dos
grupos usuarios, estando in lusive numa rede fe hada, n~ao na Internet omo aqueles
servidores.
Por outro lado, e possvel simpli ar este esquema geral ompleto do PMC no aso de
lusters pequenos, de forma a diminuir os ustos, omo sera dis utido na se ~ao 5.6. Neste
aso pode-se hegar a ombinar as fun ~oes do servidor de dis o do PMC om o servidor
de dis o de um grupo usuario, mediante alguns ompromissos te ni os a eitaveis.
Front-End: tem a fun ~ao de servir de portal de entrada para o a esso dos usuarios ao
sistema e de sada para os dados produzidos. Deve ser uma maquina de porte se-
~ DE CADA COMPONENTE DO PMC

2.2. FUNC
AO
melhante ao dos nos. Tambem podera ser usado para rodar programas de ontrole
jobs de pro essamento paralelo.
Servidor: tem a fun ~ao de prover os servi os de dis o e de rede para permitir o fun ionamento dos nos. Ate varias dezenas de nos basta um servidor de porte semelhante
ao dos nos. Para sistemas muito grandes pode ser ne essario instalar mais de um
servidor de dis o, ou instalar uma liga ~ao de rede de 1 Gbps, atraves de bras
oti as ou de abos TP.
Terminal: tem fun ~oes variadas, sendo as mais importantes: servir de terminal gra o
X11 para fun ~oes de administra ~ao do sistema; servir omo onsole de boot para
os nos; servir omo no virtual para upgrades dos sistemas dos nos; servir omo plataforma de testes e ajustes para variadas opera ~oes de hardware, software e rede.
Esta maquina n~ao deve ser usada regularmente omo um no de pro essamento.
No: ada no e uma unidade de pro essamento numeri o. Eles devem atuar todos em
onjunto para rodar um programa paralelo. Quanto maior o numero de nos disponveis, maior o poder geral de pro essamento. N~ao ha nenhum limite te ni o
relevante para o numero de nos, os limites relevantes ser~ao sempre nan eiros. Na
prati a, podemos pensar em ate er a de 100 nos omo exemplo, para xar as
ideias.
Rede: trata-se de uma rede privada, que n~ao esta ligada de forma direta a Internet;
sua fun ~ao e estabele er a omuni a ~ao entre todos os omponentes do sistema. E
atraves dela que os nos bootam e operam, que mensagens de dados s~ao passadas
entre os nos, que os usuarios a essam os nos e que os resultados s~ao enviados para
fora atraves do front-end.
Seus problemas de montagem e ongura ~ao de hardware do sistema s~ao os seguintes,
na ordem em que vo ê tera de enfrenta-los:
1. Montagem e veri a ~ao de opera ~ao do front-end, in luindo a sua ongura ~ao de
setup do bios. Esta maquina deve ser ligada ao no-break on-line da Exide.
2. Montagem do equipamento de rede, possivelmente in luindo a manufatura dos
abos UTP para a liga ~ao om todos os outros omponentes do PMC. A maquina
de rede deve ser ligada ao no-break Exide.
3. Montagem e veri a ~ao de opera ~ao do servidor, in luindo a sua ongura ~ao de
setup do bios e a ongura ~ao do setup da pla a SCSI. Esta maquina deve ser
ligada ao no-break Exide.
4. Montagem e veri a ~ao de opera ~ao do terminal, in luindo a sua ongura ~ao de
setup do bios; esta maquina estara frequentemente sendo aberta e possivelmente
modi ada no futuro. Esta maquina deve ser ligada ao no-break Exide.
10
5. Montagem e veri a ~ao de opera ~ao dos nos, in luindo a sua ongura ~ao de setup
do bios, o que sera feito om a ajuda de algumas pe as do terminal. Estas maquinas
devem ser ligadas aos no-breaks simples, om no maximo 8 nos por no-break.
2.3 Des ri ~ao Detalhada dos Componentes

Damos aqui uma des ri ~ao razoavelmente detalhada mas dis ursiva de ada um dos
omponentes do sistema PMC. Listas das pe as ne essarias para a montagem de ada
omponente, om des ri ~oes te ni as, mar as, modelos e pre os, podem ser en ontradas
no apêndi e B.
Front-End: trata-se aqui de uma maquina muito pare ida om o terminal des rito
abaixo. Ela deve ser montada em um gabinete padr~ao ATX midi-torre e deve ter
dois dis os lo ais padr~ao IDE. A motherboard, o pro essador e a memoria podem
ser as mesmas de um no. As pla as de rede tambem podem ser do mesmo tipo,
mas sera ne essario olo ar duas delas, uma para a rede privada e outra para a
liga ~ao a Internet atraves da LAN.
A maquina deve ontar tambem om uma pla a de vdeo simples, um monitor
VGA de 14", unidade oppy, te lado e mouse. O monitor sera usado apenas omo
onsole de boot do front-end e para opera ~oes de administra ~ao. Ele sera usado
apenas em modo de texto, n~ao sera rodado nele o sistema X11. O mouse sera
usado apenas neste modo de texto.
Servidor: trata-se aqui de uma maquina tpi a para atuar omo servidor de pequenos
grupos. Deve ser montada num gabinete padr~ao ATX grande e de boa qualidade
(full-tower). A motherboard, o pro essador e a memoria podem ser as mesmas de
um no, mas para os sistemas maiores pode ser vantajoso olo ar uma quantidade
maior de memoria RAM, ou mesmo usar uma maquina bi-pro essada ou mais de
uma maquina. A pla a de rede tambem pode ser do mesmo tipo.
Alem disso, este servidor deve ter uma pla a ontroladora de dis os de alto desempenho e dois dis os SCSI topo de linha, tambem para garantir um alto desempenho. A maquina deve ontar tambem om uma pla a de vdeo simples, um
monitor VGA de 14", unidade oppy, te lado e mouse. O monitor sera usado
apenas omo onsole de boot e para opera ~oes de administra ~ao. Ele sera usado
apenas em modo de texto, n~ao sera rodado nele o sistema X11. O mouse sera
usado apenas neste modo de texto.
Terminal: trata-se aqui da maquina tpi a para atuar omo terminal gra o para um
usuario. Para melhor desempenhar as suas fun ~oes, sua motherboard, seu pro essador e sua pla a de rede devem ser idênti os aos dos nos. Ela deve ser montada
em um gabinete padr~ao ATX mini-torre, deve ter dois dis os lo ais padr~ao IDE,
11
~ DETALHADA DOS COMPONENTES

2.3. DESCRIC
AO
FORA
RESET
RAM
CPU
PLACA
DE
REDE
KB
PORTAS SERIAIS
Figura 2.2: Ilustra ~ao de um no de pro essamento, visto de ima.

uma boa pla a de vdeo tipo AGP om pelo menos 8 MB de RAM, um monitor de
17" de boa qualidade, unidade oppy, te lado e mouse, bem omo outras unidades
de I/O tais omo CDROM e ZIP.
Esta maquina n~ao deve ser utilizada omo um no de pro essamento, pois alem de
servir omo onsole dos nos e uni o terminal gra o dentro da rede privada, ela
pode ter de ser rebootada e ate aberta e par ialmente desmontada para testes e
ajustes de hardware e software. Ela n~ao deve, de fato, estar a essvel para todos
os usuarios do sistema, mas apenas pelo pessoal envolvido om a manuten ~ao e o
geren iamento.
No: o no de pro essamento e uma maquina extremamente simples, om apenas 5 pe as:
trata-se de uma motherboard no padr~ao ATX om um pro essador, uma unidade
de memoria RAM (que pode onsistir de um ou dois DIMMs), uma pla a de rede
PCI de alto desempenho e uma fonte padr~ao ATX, de 300 W. Em seu modo normal
de opera ~ao toda a omuni a ~ao om o no sera feita atraves da rede. Isto in lui
o boot do sistema, a montagem dos dis os de sistema, que s~ao feitos a partir do
servidor, bem omo o a esso pelos usuarios e a montagem dos dis os de home,
que s~ao feitos a partir do front-end. Um diagrama ilustrativo de um no pode ser
en ontrado na gura 2.2.
Adi ionalmente, devem ser olo ados diretamente na motherboard dois bot~oes de
ontato momentâneo (\power" e \reset") e um ou dois leds (\power" e, possivelmente, \beep"). A forma mais simples de fazer isto e solda-los diretamente
aos ontatos da motherboard. Os nos ser~ao montados e simplesmente olo ados
para fun ionar em uma estante de madeira. N~ao ha ne essidade de gabinetes, os
12
quais, alem disso, em geral o upam muito espa o, o que pode ser um problema se
tivermos um grande numero de nos.
Rede: trata-se de um equipamento padr~ao utilizado em redes lo ais. Pode ser mais ou
menos rapido (e aro) dependendo de suas ne essidades de omuni a ~ao entre os

nos. A alternativa padr~ao para sistemas de alto desempenho e um swit h Ethernet
de 100 Mbps, mas tambem e possvel usar um hub de 100 Mbps ou ate um simples
e barato hub de 10 Mbps, desde que as suas ne essidades de omuni a ~ao entre os
nos n~ao sejam grandes. Em breve deveremos ter Ethernet de 1 Gbps trafegando
em abos TP, mas por enquanto 100 Mbps e o melhor que se pode onseguir por
pre os razoaveis.
2.4 Des ri ~ao do Pro esso de Montagem

De forma geral o pro esso de montagem do hardware e pare ido, seja para o aso do
front-end, do servidor, do terminal ou dos nos. A diferen a prin ipal no aso dos nos
e que a montagem n~ao sera feita em um gabinete metali o, em vez disso montaremos
a motherboard e simplesmente a olo aremos numa estante junto om todos os outros
nos. Des revemos aqui as prin ipais opera ~oes de montagem. E muito importante ter
os manuais de hardware de todas as pe as que foram adquiridas, parti ularmente o da
motherboard, lê-los e seguir as instru ~oes que houver neles.
Uma observa ~ao importante: e ne essario uidado om des argas de eletri idade
estati a, aso vo ê esteja num lugar muito se o e num ambiente prop io a este tipo de
oisa (piso de arpete e ar ondi ionado, por exemplo). Para evitar problemas mantenha
o gabinete aterrado enquanto estiver trabalhando nele e fa a om frequên ia ontato om
ele ou om outros objetos metali os aterrados atraves de suas m~aos, para evitar que seu
orpo tenha uma arga eletrostati a que possa dani ar algum hip de alguma pla a. Em
geral o ambiente em nosso pas e muito humido e esta quest~ao da eletri idade estati a
n~ao e uma preo upa ~ao muito grande, mas de qualquer forma e melhor tomar todos os
uidados possveis.
2.4.1 Montagem da Motherboard

Antes de mais nada deve-se ongurar todos os \straps", \jumpers" ou \dip-swit hes"
que houver na motherboard, para ongura-la para o parti ular tipo de CPU que vai
ser instalado nela. Para isto e essen ial que se disponha do manual de instru ~oes que
vem om a motherboard. Em geral as motherboards modernas dete tam quase tudo
automati amente ou, em alguns asos, fazem as ongura ~oes atraves do seu setup, que
tambem se denomina de \bios", mas e bom veri ar isto em detalhe. O que for feito
atraves do bios pode ar para depois, mas o que for feito atraves de jumpers deve ser
feito ja.
~ DO PROCESSO DE MONTAGEM
2.4. DESCRIC
AO
13
Os straps ou jumpers s~ao pares de pinos na motherboard ujo ontato pode ser feito
pela inser ~ao neles de pequenos one tores metali os en apsulados em plasti o. Os dipswit hes s~ao pequenos interruptores multiplos soldados na motherboard, s~ao usados om
menos frequên ia. Alem de ongurar a motherboard para o seu CPU, vo ê deve usar
os straps para desativar todos os dispositivos on-board que existam na motherboard e
que n~ao ser~ao usados. Exemplos tpi os disto s~ao modems, hips de som e propriedades
de ligamento e desligamento automati o (\sleep" e \wake") da propria motherboard.
Antes de montar o CPU e a memoria RAM e uma boa ideia limpar os ontados dos
dois lados om um spray de limpeza de ontatos. Vo ê pode agora instalar o CPU em seu
lugar na motherboard, bem omo os DIMMs de memoria RAM. Cada um deles tem o seu
tipo espe o de slot. Certique-se de que ada pe a esteja bem assentada em seu slot e
n~ao se esque a de ligar o abinho de for a do dissipador do CPU no one tor adequado
da motherboard. Todos os ontatos e en aixes s~ao haveados, ou seja, os one tores
so en aixam nos soquetes orrespondente em uma determinada posi ~ao. E ne essario
apli ar alguma for a para olo ar os DIMMs de memoria RAM em seus slots. Coloque
a motherboard sobre uma superf ie rme e mantenha o seu sangue frio, apli ando a
for a que for ne essaria om uidado mas sem medo.
2.4.2 Montagem das Pe as no Gabinete
Para ome ar a montagem da maquina deve-se instalar a motherboard dentro do gabinete, ligar a ela o led de for a, os bot~oes de reset e de for a e o abo de alimenta ~ao
de for a que vem da fonte. Ligue tambem a motherboard o pequeno altofalante que
fun iona omo \beeper". As instru ~oes de omo fazer ada uma destas oisas podem
ser en ontradas no manual que vem om a motherboard. Lembre-se de que os leds, ao
ontrario dos bot~oes e do altofalante, s~ao polarizados, ou seja, pre isam ser ligados om
os ontatos na posi ~ao erta, aso ontrario n~ao a ender~ao. Os parafusos e presilhas
ne essarios em geral vêm om o gabinete, bem omo os leds e bot~oes. Em seguida se
instala nos slots apropriados da motherboard a pla a de vdeo AGP, no slot AGP, que
e marrom, a as demais pla as tipo PCI (pla a de dis os SCSI e pla a de rede) nos slots
PCI, que s~ao bran os.
Antes de montar os dis os dentro do gabinete e ne essario ongurar o seu endere amentos no bus apropriado, tanto no aso IDE quanto no aso SCSI. Veja a dis uss~ao
de ada aso nas se ~oes subsequentes, que s~ao espe as para ada omponente do seu
sistema PMC. Depois disto monta-se os dis os IDE ou SCSI no gabinete e interliga-se
estes dis os om o one tor apropriado na motherboard ou na pla a SCSI. O led de
atividade de dis os que ha no gabinete deve ser ligado a motherboard no aso de dis os
IDE e a pla a SCSI no aso de dis os SCSI. Seja qual for o tipo de dis o, deve-se lidar
om eles om extremo uidado, evitando em espe ial hoques me âni os, pois eles s~ao as
pe as me ani amente mais frageis do sistema, que envolvem pe as que se movimentam
em altas velo idades e me âni a na, de alta pre is~ao.
Neste ponto do pro esso instala-se tambem a unidade oppy, interligando-a om o
14
soquete apropriado da motherboard. Pode-se instalar tambem uma unidade CDROM

do tipo IDE ou uma unidade ZIP interna, tambem do tipo IDE, as quais devem ser
ligadas a um dos soquetes dos ontroladores IDE existentes na motherboard. Observe
que varios soquetes da motherboard poder~ao ar sem uso omo, por exemplo, os dois
para dis os IDE. Os abos internos de onex~ao de dispositivos vêm om a motherboard,
om o CDROM ou om a pla a de dis os SCSI.
Em geral ada par one tor{soquete e de um tipo diferente e, se forem de boa
qualidade, devem ser haveados, ou seja, os one tores so en aixam nos soquetes orrespondente em uma determinada posi ~ao. Caso alguns one tores n~ao sejam haveados,
deve-se ter uidado de olo a-los na posi ~ao erta, aso ontrario a maquina n~ao ira
operar. Em parti ular, isto pode ser um problema om a liga ~ao da unidade oppy e
de dis os IDE. E, geral n~ao ha ris o de alguma oisa ar dani ada se ligada errado, o
que a onte e e que a maquina simplesmente n~ao opera. A ex e ~ao seriam as onex~oes
da fonte. mas estas s~ao sempre haveadas, tanto a que alimenta a motherboard quanto
as que alimentam os dis os e demais dispositivos. Para prender e organizar em feixes os
diversos abos de onex~ao, uma vez que esteja tudo one tado, e onveniente o uso de
tas tas-presilha de nylon, onhe idas omo tas Hellermann.
2.4.3 Conex~oes ao Gabinete e Opera ~ao
Uma vez montados e one tados todos os dispositivos internos, ainda deixe o gabinete
aberto e one te a maquina o te lado, o mouse e o monitor. Feito isto vo ê esta pronto
para energizar a sua maquina pela primeira vez. Verique uidadosamente se a fonte do
gabinete esta ongurada para a tens~ao de alimenta ~ao AC do seu predio, em geral ha
nela um interruptor de 110 V/200 V, a erte-o adequadamente om uidado.
Se estiver tudo erto ligue a maquina e observe o seu omportamento atraves do
monitor, do beeper e dos leds do gabinete e dos varios dispositivos. Se a maquina
bootar o seu bios normalmente aperte a te la [Del do te lado para entrar no programa
de setup do bios da motherboard. Se a maquina parar em algum ponto e nada mais
a onte er, desligue-a e reveja a sua montagem, e muito provavel que haja uma onex~ao
errada. E muito improvavel, mas n~ao impossvel, que haja alguma pe a defeituosa.
Caso vo ê tenha problemas, retire uma pe a de ada vez ou substitua-a por outra, se
isto for possvel, ate a har o problema.
Uma vez ligada a maquina e estando os dis os ativados, girando em alta velo idade,
e ne essario parti ular uidado para n~ao submeter o gabinete a hoques me âni os e
mesmo om a sua simples movimenta ~ao. Sugere-se nun a movimentar o gabinete om
o sistema ligado. Em espe ial no aso do servidor om dis os SCSI o gabinete deve ar
permanentemente em lo al protegido, om ambiente estavel e sem trafego de usuarios
ou de outras pessoas. Para que os dis os sejam altamente onaveis e duradouros, e
importante que o servidor esteja em ambiente om temperatura estavel e n~ao muito
alta (re omenda-se o ondi ionamento de ar), livre de hoques e vibra ~oes, bem omo
de rudos na alimenta ~ao de for a, que e um dos prin ipais motivos pelos quais se
2.5. DETALHES DA MONTAGEM DO FRONT-END
15
re omenda o uso de no-breaks.

Se a maquina estiver operando orretamente desligue a maquina e fe he o gabinete.
Bom, podemos liga-la de novo, esta na hora de ongurar o seu bios. Alem de possveis
es olhas de tipo e frequên ia de CPU, aso elas n~ao tenham sido feitas automati amente
ou atraves de straps e dip-swit hes, ha varias ongura ~oes que devem ser feitas para
otimizar o fun ionamento da maquina para as fun ~oes a que se destina. Para entrar no
programa de setup do bios, aperte a te la [Del durante o boot da maquina, quando ela
estiver testando a memoria RAM. Apare er~ao menus pelos quais vo ê podera navegar
om o uso do te lado ou, as vezes, do mouse. Para se orientar sobre as es olhas, veja a
re eita de ongura ~ao no apêndi e D.1.
2.5 Detalhes da Montagem do Front-End

A montagem do front-end e pare ida om a do terminal, des rita mais adiante. Uma
das prin ipais diferen as e a ausên ia nesta maquina de um monitor gra o, basta um
monitor pequeno para ser usado em modo de texto. A outra e a existên ia de duas
pla as de rede, para que a maquina fun ione omo gateway do PMC. A velo idade de
a esso a dis o n~ao e t~ao importante aqui quanto e no servidor. Neste aso os dis os
ser~ao IDE, mais baratos e menos sus eptveis aos problemas ambientais.
Em geral as motherboards têm on-board dois ontroladores de dis os IDE, denominados de \primary" e \se ondary", orrespondendo ada um deles a um dos dois
soquetes para dis os IDE da motherboard. Os dis os IDE devem ter os seus endere amentos ongurados antes de serem montados no gabinete. Isto e feito atraves de
jumpers lo alizados na pla a ontroladora do proprio dispositivo, que e parte do orpo
do mesmo. Cada ontrolador IDE pode ontrolar ate dois dispositivos, om endere os
que s~ao hamados de \master" e \slave". Em geral a posi ~ao e ongura ~ao dos jumpers
est~ao des ritas no orpo do dispositivo.
O dis o de sistema deve ser ongurado omo dispositivo master do ontrolador
primario de sua motherboard. O segundo dis o, que vo ê pode olo ar nesta maquina e
que podera ser usado temporariamente para montar um espelho, pode ser o master do
ontrolador se undario. Desta forma os dois dis os podem ser usados simultaneamente
om maior e iên ia, pois ada um estara usando um ontrolador separado.
Alem dos ontroladores IDE, deve-se deixar ativadas as portas seriais, que ser~ao
utilizadas para one tar o mouse e, possivelmente, para a esso ao onsole serial dos nos,
so o mouse utilizado n~ao for serial. Uma das portas seriais deve ser reservada para o
abo de ontrole do no-break Exide. Uma das atividades adi ionais na montagem do
front-end sera a manufatura de um abo ustomizado para este m.
16
Endere o Jumper 3 Jumper 2 Jumper 1 Jumper 0

0
1
2
3
4
5
6
Tabela 2.1: Tabela de endere amento de dispositivos SCSI num bus de 16 bits; os
retângulos pretos indi am jumpers fe hados, os bran os jumpers abertos.
2.6 Detalhes da Montagem do Servidor

A montagem do servidor de dis os se pro essa omo a montagem de qualquer servidor de
uso geral, departamental ou de um grupo de pesquisa. Os ontroladores IDE existentes
na motherboard n~ao ser~ao usados e devem ser desativados no setup. Ser~ao usados neste
servidor dis os SCSI de alto desempenho e grande onabilidade.
Os dis os SCSI devem ter o seu endere amento ongurado antes de serem montados
no gabinete. Isto e feito atraves de jumpers lo alizados na pla a ontroladora do proprio
dis o, que e parte do orpo do mesmo. Dispositivos SCSI modernos, do tipo \wide" ou
\LVD", omo os que re omendamos aqui, podem ter endere os que variam de 0 a 15.
Como a propria pla a SCSI usa um destes endere os (em geral o 7), e possvel olo ar ate
15 dispositivos diferentes em um bus SCSI. Este numero de endere amento e ontrolado
por um onjunto de 4 jumpers, em geral numerados de 0 a 3 ou de 1 a 4. Cada jumper
determina um bit de um numero binario de 4 bits que e o endere o do dispositivo no
bus. Fe har o jumper signi a 1, deixar ele aberto signi a 0. O dis o de sistema do
servidor deve ser olo ado no endere o 0, que e, por default, o endere o do dis o de boot.
Os demais dis os devem ser olo ados nos endere os subsequentes, de forma que vo ê
ertamente n~ao vai utilizar endere os alem do 6. A tabela 2.1 mostra as ongura ~oes
dos endere os que nos interessam aqui.
Alem da ongura ~ao de endere o no bus, e ne essario ongurar mais duas oisas
em um dis o SCSI generi o: uma e a termina ~ao interna do dis o, que deve ser ativada
apenas no aso do dis o ser o ultimo dispositivo one tado ao abo SCSI, que fun iona
omo um bus, ou seja um guia de ondas. A termina ~ao serve para impedir que o sinal que
se propaga no bus, ao longo do abo de dados, seja re etido na ponta deste e retorne ao
bus, o que provo aria interferên ia e possvel dupli a ~ao indevida de dados. Para dis os
do tipo LVD, omo os que re omendamos aqui, esta opera ~ao n~ao e ne essaria porquê
os terminadores ja est~ao montados omo parte integrante dos abos. A outra oisa que
deve ser ongurada e o status de partida do motor do dis o quando ele e energizado.
E onveniente ongurar todos os dis os para n~ao ini iar seus motores imediatamente,
2.7. DETALHES DA MONTAGEM DO TERMINAL
17
esperando, em vez disso, um sinal da pla a SCSI. Desta forma a pla a SCSI podera
ini iar um dis o de ada vez, evitando a possibilidade de uma sobre arga momentânea
da fonte de alimenta ~ao, em parti ular se houver varios dis os, pois eles puxam muita
orrente durante a partida e d~ao um tran o na fonte.
Observe que os dis os SCSI, que em geral esquentam bastante e requerem boa refrigera ~ao, em espe ial se forem modelos de topo de linha, om velo idades altas de rota ~ao,
pre isam ser instalados de forma apropriada e uidadosa, pois trata-se dos omponentes
mais frageis do sistema. A melhor forma de montar estes dispositivos de 3-1/2" e nas
baias de 5-1/4" do gabinete, atraves do uso de trilhos de adapta ~ao para montagem de
dis os de 3-1/2" em baias de 5-1/4", que vo ê tera de omprar a parte. Desta forma a
refrigera ~ao sera a melhor possvel. Observe que o gabinete deve ter pelo menos duas
e idealmente quatro ventoinhas montadas em suas paredes. Alem disso, retire e deixe
abertas as tampas plasti as que ha da frente do gabinete e que orrespondem as baias
que vo ê usou para olo ar os dis os.
No aso do servidor, alem de ongurar o bios da motherboard, omo deve ser feito
em todas as maquinas, vo ê devera veri ar a ongura ~ao do bios da sua pla a SCSI.
Para entrar no programa de setup do bios da pla a SCSI, no aso das pla as Adapte que
re omendamos aqui, aperte as te las [Ctrl-A quando apare er na tela uma mensagem
da pla a SCSI sobre isto. Apare era um sistema de menus no qual vo ê podera navegar
om o te lado. Suas tarefas de ongura ~ao s~ao: veri ar que o dis o de boot esta
orretamente ongurado omo o dis o ujo endere o SCSI e 0; desativar quaisquer
op ~oes relativas ao sistema DOS, que servem para ontornar limita ~oes daquele sistema,
bem omo veri ar as outras op ~oes; ongurar a partida automati a, durante o boot,
dos dis os que de fato existem. Para se orientar sobre as op ~oes, veja a re eita de
ongura ~ao no apêndi e D.1. Observe que e possvel veri ar a superf ie e ate formatar
os dis os em nvel baixo atraves da pla a SCSI. Isto n~ao deve ser feito de forma alguma
em dis os que n~ao apresentem problemas muito graves de hardware.
2.7 Detalhes da Montagem do Terminal

A montagem do terminal se pro essa omo a montagem de qualquer terminal gra o
de uso geral de um membro de um departamento ou grupo de pesquisa. Para este tipo
de equipamento uma boa pla a de vdeo e um bom monitor s~ao mais importantes do
que velo idade de CPU ou de a esso a dis o. Neste aso os dis os ser~ao IDE. Tambem
e onveniente ter neste tipo de equipamento unidades de entrada e sada tais omo
CDROMs e ZIPs.
Em geral as motherboards têm on-board dois ontroladores de dis os IDE, denominados de \primary" e \se ondary". Alem de dis os rgidos, unidades CDROM e ZIP
podem ser ligadas a estes one tores. Todas as unidades IDE devem ter os seus endere amentos ongurados antes de serem montados no gabinete. Cada ontrolador IDE
pode ontrolar ate dois dispositivos, om endere os que s~ao hamados de \master" e
18
\slave". Em geral a posi ~ao e ongura ~ao dos jumpers est~ao des ritas no orpo do
dispositivo.
O dis o de sistema deve ser ongurado omo dispositivo master do ontrolador
primario de sua motherboard. O segundo dis o, que vo ê deve olo ar nesta maquina
e que sera usado para outras fun ~oes, pode ser o master do ontrolador se undario.
Desta forma os dois dis os podem ser usados simultaneamente om maior e iên ia,
pois ada um estara usando um ontrolador separado. As unidades CDROM e ZIP, se
houver, devem ser olo adas nas posi ~oes slave dos ontroladores primario e se undario,
respe tivamente.
Alem dos ontroladores IDE, deve-se deixar ativada no setup a porta paralela, que
sera utilizada para a liga ~ao do gravador de eprom ou de eeprom que vo ê devera adquirir
para poder gravar os hips de boot dos nos. As portas seriais tambem dever~ao ser usadas,
uma para o mouse e outra para a esso ao onsole serial dos nos.
2.8 Detalhes da Montagem dos Nos

No aso dos nos ha algumas opera ~oes adi ionais a realizar durante a montagem da
motherboard. Como elas n~ao ser~ao montadas em gabinetes tradi ionais, e ne essario
provê-las de um bot~ao de power-on, de um led de for a, de um bot~ao de reset e, possivelmente, de um led de beep no lugar do altofalante. Sera ne essario adquirir em
alguma loja de eletrôni a leds nas ores verde e amarela ou vermelha, alem de pequenos interruptores miniatura de ontato momentâneo. Estes elementos ser~ao xados por
meio de soldagens, diretamente nos pinos de ontato orrespondentes da motherboard.
Trata-se de soldagem de baixa temperatura, omo se usa rotineiramente em eletrôni a,
om o uso de um pequeno ferro de solda de 20 ou 30 W e os de solda de estanho.
Adquira interruptores de duas ores diferentes e solde um aos ontatos de reset e outro
aos ontatos de power-on da motherboard. A gura 2.5 ilustra o resultado nal que se
espera obter.
O led verde deve ser soldado aos ontados do led de for a, o led amarelo ou vermelho
deve ser soldado aos ontatos do altofalante. Lembre-se de que os leds tem polaridade.
A ideia do led de beep olo ado no lugar do altofalante e que os beeps de aviso e de erro
do sistema sejam dete taveis visualmente. E dif il identi ar quem beepou em uma
estante om dezenas de nos. Entretanto, n~ao e garantido que isto fun ione em toda e
qualquer motherboard, vo ê tera de experimentar um pou o para ver. Em alguns asos
podera fun ionar, a endendo o led quando ha um beep, em outros asos o led pode
ar sempre a eso e apagar momentaneamente quando ha um beep, em outros isto n~ao
vai fun ionar de todo. Experimente om uma motherboard para ver se onsegue algum
sinal de beep. Se n~ao for possvel n~ao se preo upe, isto esta muito longe de ser algo
essen ial.
Enquanto o front-end, o servidor e o terminal ser~ao montados da forma usual em gabinetes metali os, os nos podem ser simplesmente olo ados em uma estante de madeira.
19

2.8. DETALHES DA MONTAGEM DOS NOS
1
0
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0000000000000000000
1111111111111111111
0
1
0
1
0000000000000000000
1111111111111111111
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
1111111111111111111
0000000000000000000
0
1
0
1
0
1
0
1
0
1
0
1
1111111111111111111
0000000000000000000
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
1111111111111111111
0000000000000000000
0
1
0
1
0
1
0
1
0
1
0
1
0000000000000000000
1111111111111111111
0
1
0
1
0000000000000000000
1111111111111111111
0
1
0
1
0
1
0
1
0
1
0
1
0000000000000000000
1111111111111111111
0000000000000000000
1111111111111111111
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0000000000000000000
1111111111111111111
0000000000000000000
1111111111111111111
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
1111111111111111111
0000000000000000000
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
11111111111111111111
0000000000000000000
0
1
0
1
0
1
0
1
0
1
0
1
0000000000000000000
1111111111111111111
0
1
0
1
0000000000000000000
1111111111111111111
0
1
0
1
0
1
0
1
105 cm
209 cm
1111111111111111111
0000000000000000000
0000000000000000000
1111111111111111111
11
00
0
1
0000
0000
1111
001111
11
0
1
1111
0000
00
11
0
1
001111
11
0
1
0000
00
11
0
1
0000
1111
00
11
0
1
00
11
0
1
00
11
0
1
00
11
0
1
1111
0000
00
11
0
1
00
11
0
1
000000
11
0
1
1111
00
11
0
1
00
11
0
1
00
11
0
1
0000
001111
11
0
1
0000
1111
00
11
0
1
00
11
0
1
00
11
0
1
0000
001111
11
0
1
0000
1111
00
11
0
1
1111
0000
00
11
0
1
00
11
0
1
0000
001111
11
0
1
0000
1111
00
11
0
1
00
11
0
1
00
11
0
1
0000
1111
0000
1111
00
11
0
1
00
11
0
1
00
11
0
1
00
11
0
1
1111
0000
00
11
0
1
00
11
0
1
00
11
0
1
00
11
0
1
1111
0000
00
11
0
1
00
11
0
1
00
11
0
1
0000
001111
11
0
0000
1111
11111
0000
00
11
0
1
00
11
0
1
28 cm
Figura 2.3: Um modulo da estante de madeira de 209 m de altura para a montagem

dos nos, om espa o para ate 20 nos; um modulo de 249 m de altura pode abrigar ate
24 nos.
20
FONTE
CPU
CPU
REDE
FONTE
CPU
18 cm
REDE
CPU
FONTE
CPU
20 cm
REDE
FONTE
REDE
CPU
FONTE
REDE
FONTE
REDE
11
00
00
11
00
11
00
11
00
11
00
11
00
11
00
11
11111111111111111111111111111111111
00000000000000000000000000000000000
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
1111111111111111111111111111111111111
00000000000000000000000000000000000
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00000000000000000000000000000000000
11111111111111111111111111111111111
00
11
00
11
00000000000000000000000000000000000
11111111111111111111111111111111111
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
11
00
1111111111111111111111111111111111111
00000000000000000000000000000000000
00
11
00
11
00
11
00
11
00
11
00
11
95 cm
100 cm
Figura 2.4: Parte de um modulo da estante de madeira para a montagem dos nos,
mostrando seis destes nos em seus lugares.
RESET
BEEP
POWER
1111
0000
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
POWER
11111
00000
00000
11111
00000
11111
00000
11111
00000
11111
00000
11111
00000
11111
00000
11111
00000
11111
MOTHERBOARD
Figura 2.5: Diagrama mostrando os bot~oes de ontato momentâneo e os leds soldados

aos pinos da motherboard. A posi ~ao dos pinos e apenas ilustrativa, pois depende da
parti ular motherboard que for de fato usada. O bot~ao vermelho e o de reset, o azul
o de power-on/o, ores estas que s~ao ompletamente arbitrarias. O led amarelo (ou
vermelho) deve ser o de beep, o verde deve ser o de power.
2.9. MONTAGEM DO EQUIPAMENTO DE REDE
21
Estantes de metal devem ser evitadas, para prevenir a possibilidade de urto- ir uitos
quando se olo a a motherboard sobre as suas prateleiras. Alem disso, e fa il parafusar
e prender oisas em prateleiras de madeira. Mas n~ao e realmente ne essario parafusar os
nos nas prateleiras. Desde que a estante que em lo al isolado, sem trafego de usuarios
e outras pessoas, podemos simplesmente olo ar os nos nas prateleiras e deixa-los la
pro essando onfortavelmente. Uma possibilidade mais simples e atraente e xar os nos
as prateleiras atraves do uso de tas olantes dos dois lados.
A estante deve ser modular, para permitir a fa il expans~ao do sistema. Um modulo
de uma estante deste tipo pode ser visto na gura 2.3 e um setor de um modulo, om
mais detalhes, na gura 2.4. Os modulos da estante devem ter a espessura padr~ao de
28 m e largura de 105 m. Com montantes laterais de 209 m de altura e possvel
olo ar 20 nos em um modulo da estante. Ja om montantes de 249 m de altura e
possvel olo ar ate 24 nos em ada modulo. Se deixarmos a prateleira de baixo livre
para a olo a ~ao de no-breaks para os nos estes numeros se reduzem para 18 e 22 nos
por estante, respe tivamente. Os modulos tambem podem ser obtidos om montantes
de 109 m de altura, permitindo a montagem de 10 ou 8 nos respe tivamente, bem omo
om montantes de outras alturas.
Deve haver a esso a estante pelos dois lados. Por um deles v~ao ser one tados os
abos da rede, bem omo os abos seriais para monitora ~ao de boot atraves do onsole
serial. Pelo outro lado passar~ao os abos de for a das fontes. Deste segundo lado ar~ao
tambem os leds e bot~oes de for a e de reset. Aqui tambem pode ser muito util o uso de
tas Hellermann para prender e organizar todos os abos.
A ongura ~ao de setup dos nos e um pou o diferente do usual. Alem de desativar
tudo que n~ao estiver sendo usado omo, por exemplo, o ontrolador de oppy e os
ontroladores de dis os IDE, deve-se ongurar o setup para n~ao interromper o boot no
aso de erros. Isto deve ser assim pois n~ao havera te lado ou pla a de vdeo ligadas a
maquina, eventos que ser~ao dete tados pelo bios e interpretados omo erros. As portas
seriais devem ser mantidas ativadas, pois ser~ao utilizadas omo onsoles de boot do
sistema.
2.9 Montagem do Equipamento de Rede

N~ao ha muito o que fazer para a montagem do equipamento de rede. Basta liga-lo ao
no-break junto om o front-end, o servidor e o terminal, ligando em seguida os abos de
rede, de um lado as portas do equipamento de rede e de outro a ada uma das demais
maquinas. Como havera muitos abos entre os nos e este equipamento, ele deve ser
olo ado na estante, juntamente om os nos. De la sair~ao os três abos de rede que
ligar~ao o front-end, o servidor e o terminal. Caso seja ne essario montar estes dois
equipamentos a uma erta distân ia do resto do onjunto, estes três abos devem ser
abos UTP padr~ao, om os rgidos, o que permite que sejam muito mais longos.
Cabos exveis podem ser omprados prontos, ja one torizados ( om os one tores
22
UTP montados em suas pontas). Trata-se de \pat h- ords", que s~ao abos UTP bem
exveis. E muito onveniente usar estes abos exveis, o que e possvel desde que
as liga ~oes n~ao sejam muito longas ( abos de, no maximo, alguns pou os metros), em
parti ular no aso dos nos, que am soltos na prateleiras. Desta forma os abos de rede
n~ao exer er~ao for as apre iaveis sobre as motherboards. Os abos podem ser organizados
e presos atraves do uso de tas Hellermann. N~ao se deve apertar muito os abos, apenas
organiza-los em feixes frouxos.
Por outro lado, om os abos presos e portanto imoveis, n~ao ha problema em se usar
abos UTP rgidos para ligar os nos, em espe ial se xarmos os nos nas prateleiras om
tas olantes. Os abos rgidos, alem de mais baratos e de melhor desempenho, podem
ser feitos na propria institui ~ao, atraves do uso de um simples ali ate de rimpagem.
Captulo 3
Software
3.1 Como o Sistema todo Opera
O seu sistema PMC e, na realidade, uma simples rede de omputadores, que vai fun ionar, de forma geral, omo a rede lo al de uso geral de sua institui ~ao. Trata-se,
entretanto, de uma rede privada, que so esta one tada a Internet atraves do front-end.
Cada no de seu PMC e um omputador autônomo no qual roda um sistema opera ional
ompleto. Trata-se, entretanto, de um omputador reduzido aos omponentes mnimos
para a sua fun ~ao de maquina de pro essamento. Note que os nos n~ao têm nenhum tipo
de mdia magneti a e prati amente nenhuma pe a movel (a ex e ~ao e a ventoinha do
dissipador do CPU), o que aumenta muito a sua onabilidade opera ional. Todos os
dis os est~ao no servidor, que e um servidor de dis o e rede tpi o. Trata-se aqui de uma
maquina bem mais omplexa e ompleta mas, ainda assim, sem um sistema gra o X11
em seu onsole. A fun ~ao do software de sistema e fazer om que este onjunto todo
opere de forma onveniente para os usuarios.
Os nos e o front-end s~ao integrados atraves da rede para forne erem aos usuarios um
ambiente omputa ional homogêneo e transparente. O onjunto do front-end e dos nos
pare era ao usuario ser um uni o sistema. Com algumas pou as diferen as, o uso deste
sistema se pro essara de forma idênti a ao uso do seu sistema omputa ional de uso
geral. Partindo de seu sistema home de uso geral, o usuario podera entrar no front-end
atraves da rede lo al da sua institui ~ao, usando os proto olos usuais de rede: telnet,
rlogin, ssh. A partir do front-end ele podera a essar ou submeter jobs remotamente aos
nos da rede privada. Com o uso do PVM ou do MPI ele tambem podera fazer isto, mas
de forma bem mais automatizada. Programas de ontrole de PVM ou MPI podem ser
rodados no proprio front-end, mas n~ao se deve rodar nele programas de pro essamento
intensivo.
Como todos os dis o do sistema est~ao lo alizados no servidor, os nos bootam seus
sistemas a partir dele atraves da rede, usando os proto olos DHCP e TFTP, bem omo o software Etherboot de boot remoto atraves da rede. Uma vez bootados, os nos
23
24
CAPITULO 3. SOFTWARE
tambem montam todos os seus lesystems de sistema a partir do servidor, atraves dos
sistemas NFS-root e NFS. A uni a maquina que n~ao deve estar a essvel aos usuarios
do sistema e o terminal, que sera usada apenas para fun ~oes de instala ~ao, monitora ~ao,
administra ~ao, testes e manuten ~ao. O servidor de dis o pode, mas n~ao pre isa, estar
disponvel para os usuarios.
Seus problemas de instala ~ao e ongura ~ao do sistema s~ao os seguintes, na ordem
em que vo ê tera de enfrenta-los:
1. Instala ~ao do sistema opera ional Linux, distribui ~ao Debian, no front-end, in luindo a sua ongura ~ao na rede lo al de uso geral da sua institui ~ao e na rede
privada do PMC.
2. Instala ~ao e ongura ~ao de software no front-end para prepara-lo para servir aos
sistemas na rede privada. Isto in lui providen iar a re-exporta ~ao para a rede
privada dos espelhos do kernel e da Debian, atraves de relay de NFS.
3. Instala ~ao do sistema opera ional Linux, distribui ~ao Debian, no servidor, in luindo a sua ongura ~ao na rede privada, usando os espelhos re-exportados pelo
front-end.
4. Instala ~ao e ongura ~ao de software no servidor para prepara-lo para servir dis os
aos nos na rede privada.
5. Instala ~ao ini ial do sistema opera ional Linux, distribui ~ao Debian, no terminal,
que estara fun ionando no papel do no virtual n0000, omo prepara ~ao para a
subsequente instala ~ao dos nos.
6. Transferên ia do sistema do no virtual n0000 para os dis os do servidor, a ompanhado de adapta ~oes para permitir o fun ionamento remoto do terminal omo no
virtual, atraves do sistema NFS-root.
7. Finaliza ~ao da instala ~ao do terminal para as suas fun ~oes normais de monitoramento, terminal gra o e maquina de testes.
8. Compila ~ao e instala ~ao de kernels ustomizados em todos os sistemas, em parti ular para os nos, seguida do primeiro boot do no n0000 atraves da rede e de sua
ongura ~ao nal.
9. Copia dos sistemas de arquivos do no virtual para riar os sistemas de arquivos
dos nos reais, naquele dis o do servidor que e dedi ado aos nos, a ompanhado
de ajustes de ongura ~ao e de um pro edimento espe ial para poupar grandes
quantidades de espa o em dis o.
10. Abertura de ontas de usuarios no front-end, bem omo montagem remota e reexporta ~ao dos seus lesystems de home.
3.2. PAPEL DE CADA ELEMENTO DE SOFTWARE
25
Durante este pro esso vo ê tera de ompilar o kernel do Linux, bem omo outros
softwares, varias vezes.
3.2 Papel de ada Elemento de Software

O papel dos elementos basi os do sistema Linux, tais omo o kernel e a shell, s~ao
aqui os mesmos que eles têm em qualquer sistema omo, por exemplo, o seu sistema
omputa ional de uso geral. Vamos des rever aqui o papel dos elementos de software
que s~ao mais espe os da arquitetura de nosso PMC. Segue uma des ri ~ao do papel
de ada elemento de software de sistema do ponto de vista de um no, na ordem em que
eles entram em opera ~ao durante o boot deste no.
Etherboot: tem duas fun ~oes: primeiro, provê as imagens rom que ser~ao es ritas nos
hips de boot remoto que ser~ao olo ados nas pla as de rede dos nos, permitindo
o boot do kernel do Linux atraves da rede; segundo, provê o programa mknbi que
transforma uma imagem normal do kernel do Linux em uma imagem bootavel
atraves da rede, ontendo toda a informa ~ao ne essaria para que ada no a he e
monte o seu lesystem raiz atraves do sistema NFS-root. Tanto as imagens quanto
o programa ser~ao ompilados no servidor. O programa sera usado no servidor e
as imagens ser~ao es ritas, primeiro em oppies para testes, depois nos hips de
eprom ou eeprom, om o uso do terminal para tal m. Eles tambem poder~ao ser
gravados em hips de boot do tipo ash-eprom, aso no qual n~ao ha a ne essidade
de uso do terminal.
DHCP: trata-se de um daemon de servi o de rede que estara rodando no servidor; sua
fun ~ao e responder a soli ita ~oes feitas por broad ast pelos nos e forne er a ada
um, baseado na identi a ~ao de hardware de ada pla a de rede, suas informa ~oes
basi as de rede, tais omo o hostname, o seu endere o IP, o endere o IP de seu
servidor e o nome do seu kernel.
TFTP: trata-se de um daemon de servi o de rede que estara rodando no servidor; sua
fun ~ao e transmitir a ada no, atraves do proto olo TFTP (Trivial File Transfer
Proto ol) da Internet, o seu kernel quando este o soli itar atraves da rede.
NFS-root: o kernel do Linux que fun ionara nos nos pre isa ser ompilado de forma
espe ial, om uma serie de op ~oes espe as que permite a montagem da raiz
por meio de NFS. E a isto que se hama de sistema NFS-root. O kernel dos nos
podera ser ompilado tanto no servidor quanto no no virtual n0000, ou mesmo no
front-end. Estes kernels basi os ser~ao transformados em kernels bootaveis atraves
da rede no servidor e residir~ao nele permanentemente.
26
NFS: uma vez bootado o kernel de um determinado no e montada a sua raiz, ele
montara os seus demais lesystems de sistema atraves da rede, a partir do servidor, atraves do proto olo NFS (Network File System). Trata-se de um daemon
de servi os de rede que estara rodando tanto no front-end quanto no servidor.
No servidor ele serve para exportar para os nos os seus lesystems de sistema.
No front-end este sistema sera usado para re-exportar para os nos os homes dos
usuarios, bem omo os espelhos da distribui ~ao Debian e do kernel.
NFS-relay: para que os usuarios possam, a partir dos nos do PMC, ler e es rever
arquivos diretamente em seus homes em suas maquinas de uso geral de origem, e

ne essario que os lesystems de home destas maquinas sejam montados nos nos.
Entretanto, esta montagem n~ao pode ser feita diretamente, pois os nos est~ao numa
rede privada que n~ao se one ta diretamente a Internet. Assim, esta montagem
deve ser feita de forma indireta atraves do front-end.
Trata-se do que se hama de re-exporta ~ao ou \relay" de NFS: os homes de origem
de todos os usuarios s~ao montados normalmente no front-end e o servidor NFS
deste re-exporta estes lesystems para os nos. Devido ao fato de que re entemente
o orreram grandes mudan as no sistema de NFS do Linux, neste momento ha um
problema te ni o relativo a este pro edimento, o que nos for a a usar servidores
de NFS diferentes, um no front-end e outro no servidor de dis o, veja a dis uss~ao
na se ~ao A.1 dos apêndi es.
NIS: e ne essario que ada um dos nos e o front-end disponham de todas as informa ~oes
sobre os usuarios, tais omo sua existên ia, seus usernames, suas passwords, et .
Sem isso os usuarios n~ao poderiam usar de fato os sistemas. Em espe ial se houver
um grande numero de nos, e obvio que seria extremamente laborioso e in onveniente adastrar ada usuario em ada um dos nos. O sistema NIS e uma estrutura
de software que distribui este tipo de informa ~ao entre todos os nos.
Os usuarios ser~ao adastrados uma uni a vez no front-end e toda a informa ~ao
relevante estara disponvel para todos os nos. O front-end sera o servidor de NIS e
os nos ser~ao lientes do sistema NIS. Outras informa ~oes de sistema tambem podem
e devem ser distribudas atraves do NIS. Por exemplo, o adastro dos endere os
IP de todos os sistemas da rede privada, ontido no arquivo /et /hosts do frontend, pois esta rede privada n~ao tera um sistema DNS de resolu ~ao de nomes em
endere os e vi e-versa, omo e o aso usual na Internet.
3.3 Pro edimento Geral de Instala ~ao

O pro esso ini ial de instala ~ao do sistema opera ional sera sempre o mesmo, tanto
para o front-end quanto para o servidor, para o terminal e para os nos. As diferen as
apare er~ao quando se for es olher o onjunto de pa otes de software a ser instalado em
~
3.3. PROCEDIMENTO GERAL DE INSTALAC
AO
27
ada sistema e na ongura ~ao de ada um deles para exer er as suas fun ~oes dentro do
onjunto. No aso dos nos havera opera ~oes adi ionais a realizar e as diferen as ser~ao
maiores. Entretanto, o pro edimento ini ial segundo o qual se instala a base do sistema
e sempre o mesmo.
Para des rever a instala ~ao vamos assumir que ja exista um espelho da distribui ~ao
Debian disponvel na rede lo al de sua institui ~ao, a essvel atraves de FTP e NFS. Se
n~ao for o aso, pode-se instalar a primeira maquina (que sera o front-end) a partir dos
CDROMs da Debian, sem muitas altera ~oes em rela ~ao ao que sera dito aqui. Neste
aso e ne essario que haja, pelo menos temporariamente, uma unidade CDROM no
front-end e uma de suas tarefas durante a instala ~ao do front-end sera justamente a
de montar um tal espelho, se forma que a instala ~ao das maquinas subsequentes ja
possa fazer uso dele. Ha tambem a alternativa de instalar tudo diretamente a partir
do site da Debian. Isto ostumava ser desesperadamente lento, mas grandes melhorias
que foram feitas re entemente nos ba kbones de rede do pas, in luindo as liga ~oes
interna ionais, tornaram esta alternativa viavel em muitos lugares. E laro que om
toda a probabilidade isto ainda vai ser onsideravelmente mais lento do que usar um
espelho lo al ou um CD.
Para ini iar o pro esso de instala ~ao vo ê tera de puxar do espelho e es rever em
disquetes as imagens binarias dos seguintes oppies de instala ~ao: \res ue", que e um
oppy bootavel ontendo um kernel do Linux, \root", que ontem o lesystem raiz do
sistema de instala ~ao e 4 oppies de \driver" ontendo modulos de drivers para variados
tipos de hardware. Os arquivos tem os nomes res ue.bin, root.bin, driver-1.bin,
driver-2.bin, driver-3.bin e driver-4.bin e s~ao en ontrados no diretorio
debian/dists/potato/main/disks-i386/ urrent/images-1.44/
em qualquer espelho da distribui ~ao. O link para o site original e

http://ftp.debian.org/debian/dists/stable/main/disks-i386/ urrent/images-1.44/
Para es rever os oppies em um sistema Linux usando o primeiro oppy drive utilize o
omando dd omo, por exemplo, em
dd if=res ue.bin of=/dev/fd0
Lembre-se de que vo ê pode obter atraves do seu browser n~ao so os arquivos om as
imagens dos oppies de instala ~ao mas qualquer arquivo que esteja na distribui ~ao a
partir do site original, usando o link
ftp://ftp.debian.org/
28
Basi amente, vo ê vai bootar a maquina usando o oppy de res ue e seguir as instru ~oes.
O sistema de instala ~ao e bastante bem do umentado. Do umenta ~ao ompleta pode
ser obtida, por exemplo, nos links
http://latt.if.usp.br/pm /debian/
http://latt.if.usp.br/pm /debian pt.html
Vo ê tera de tomar de is~oes e fazer op ~oes sobre variadas oisas, para se orientar
olhe as re eitas de software que est~ao nas proximas se ~oes ou nos apêndi es. As op ~oes e
alternativas mostradas nestas re eitas s~ao baseadas em ampla experiên ia om sistemas
deste tipo e devem ser satisfatorias na maior parte dos asos. Quando lhe for soli itada
uma op ~ao de fonte para a obten ~ao e instala ~ao da base do sistema, es olha a alternativa
de instala ~ao atraves de NFS e forne a as informa ~oes que forem soli itadas sobre o
espelho de sua rede lo al.
Antes de ome ar o pro esso vo ê pre isa ter obtido do gerente de sua rede lo al um
endere o para o seu front-end, bem omo outras informa ~oes sobre a rede: a \netmask",
o endere o do \gateway" e o endere o de um servidor DNS. Vo ê tambem pre isa ter
es olhido um nome para o front-end, pelo qual ele sera identi ado em sua rede lo al,
bem omo soli itado o adastramento deste nome e do respe tivo endere o numeri o no
servi o de DNS da rede lo al de sua institui ~ao. Em nosso exemplo aqui este nome e
simplesmente pm . Todas as informa ~oes men ionadas a ima ser~ao ne essarias durante
a instala ~ao. Um onjunto mais ompleto de informa ~oes deste tipo se pare e om as
da tabela que segue:
endere o para a maquina: 143.107.129.150
mas ara (netmask) da rede: 255.255.255.0
endere o do gateway:
143.107.129.1
endere o do servidor DNS: 143.107.129.10
endere o de broad ast:
143.107.255.255
endere o de network:
143.107.129.0
A instala ~ao pro edera em duas fases, entre as quais o sistema sera rebootado. Vo ê
tera de denir uma password para o usuario root, que e a password administrativa do
sistema, alem do que devera abrir uma primeira onta de usuario. Sugere-se que vo ê
abra uma onta om username help e a mesma password que usou para root. Esta
onta vai fun ionar om o uma onta administrativa auxiliar, as ontas dos usuarios
reais ser~ao abertas mais tarde.
Ao terminar a instala ~ao lhe ser~ao ofere idas alternativas de instala ~ao de onjuntos
de software. Es olha a alternativa mais avan ada, de instala ~ao \ ustom". Quando
vo ê entrar no apli ativo \dsele t" es olha a op ~ao \quit" e simplesmente saia dele.
N~ao vamos instalar nenhum software adi ional agora, alem da base do sistema. Tudo
sera feito mais tarde om uso do apli ativo apt-get, de a ordo om o surgimento das
ne essidades.
~ DO KERNEL
3.4. PROCEDIMENTO DE COMPILAC
AO
29
3.4 Pro edimento de Compila ~ao do Kernel

A ompila ~ao de um kernel do Linux e uma opera ~ao que vo ê deve aprender a realizar
rotineiramente. Ao ontrario do que possa pare er, a menos da es olha de op ~oes de
ongura ~ao, trata-se de uma opera ~ao muito simples e rotineira. A es olha de op ~oes
de ongura ~ao n~ao e t~ao simples apenas devido ao grande numero de alternativas
existentes, alem de que a tomada das de is~oes orretas requer um erto onhe imento
de toda a estrutura de fun ionamento do sistema. Para auxiliar nesta parte, olo amos
nos apêndi es E.3, E.4, E.5 e E.6 imagens dos menus do sistema de ongura ~ao, om
todas as op ~oes que devem ser usadas em ada um dos quatro asos, front-end, servidor,
terminal e no.
O melhor sistema de ongura ~ao do kernel fun iona em um ambiente gra o X11, de
foram que vamos assumir que vo ê ja tenha olo ado o X11 para fun ionar no terminal
do seu PMC antes de ini iar as ompila ~oes de kernel. Alem disso, note que vo ê estara
sempre usando esta maquina omo terminal para as ompila ~oes, em todos os sistemas.
Lembre-se tambem que qualquer ompila ~ao requer que estejam instalados na maquina
onde ela a onte e os pa otes do ambiente de desenvolvimento, ontendo oisas tais omo
o ompilador g , o omando make, o assembler e as bibliote as ne essarias. Alem disso,
o sistema de ongura ~ao que usa o X11 depende dos softwares TK e TCL.
O pro edimento ompleto de ompila ~ao do kernel se ini ia om a obten ~ao atraves da
Internet de um arquivo \tar" ontendo a ultima vers~ao estavel do kernel. O pro edimento
que vamos des rever aqui e valido para as vers~oes 2.2 e 2.4 do kernel. Nas vers~oes estaveis
o segundo numero da vers~ao e sempre par. O ter eiro numero da vers~ao ompleta indi a
o nvel de \bug-x". No momento a vers~ao mais re ente do kernel 2.2 e a 2.2.18. Assim,
primeiro vo ê deve obter a partir do site do kernel ou de algum espelho o arquivo
linux-2.2.18.tar.gz
ou o arquivo de alguma outra vers~ao mais re ente. Na falta de uma espelho lo al perto
de vo ê, e sempre possvel puxar os arquivos diretamente do site do kernel, ujo endere o
e:
http://www.kernel.org
Vo ê pode obter esta vers~ao do kernel usando o link abaixo.

ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.18.tar.gz
A partir deste site entral vo ê pode a essar os sites e espelhos de onde podera puxar o
kernel por FTP ou HTTP. Uma vez obtido o arquivo, oloque-o no diretorio /usr/sr /,
o que vo ê tera de fazer omo root. Em prin pio e possvel ompilar o kernel omo
usuario, apenas para instala-lo no sistema e ne essario autoriza ~ao de root, mas por
simpli idade vamos des rever o pro esso todo assumindo que vo ê o realize omo root.
30
Em seguida va para este diretorio e verique se ja existe la um diretorio hamado
linux/, ( ujo path ompleto seria, portanto, /usr/sr /linux/). Caso ele exista mude
o seu nome para linux.OLD/ ou algo assim. Isto abre espa o para que vo ê abra a
arvore de odigo-fonte do novo kernel, o que deve ser feito om
tar -xzvf linux-2.2.18.tar.gz
Isto ira riar um novo diretorio linux/, ujo nome vo ê deve mudar para linux-2.2.18/,
registrando desta forma a vers~ao do kernel nele ontido. Como e ne essario para a ompila ~ao que a arvore pare a estar num diretorio hamado linux/, rie um \soft link" om
este nome apontando para o diretorio linux-2.2.18/, om
ln -s linux-2.2.18 linux
Alem disso vo ê deve mudar para root o \ownership" do diretorio e de todos os arquivos
que ele ontem, om o omando
hown -R root:sr linux-2.2.18
Com isto feito estamos prontos para ini iar a ompila ~ao. Entre no diretorio linux/ (e
isto mesmo, linux/ e n~ao linux-2.2.18/, pode-se tratar um soft link que aponta para
um diretorio omo se fosse um diretorio) e exe ute o omando
make x onfig
Depois de algumas ompila ~oes preliminares, apare era na tela um menu omo aquele
que se vê nos apêndi es. Vo ê podera fazer todas as op ~oes e abrir ou fe har a sequên ia
de menus e sub-menus usando o mouse. Vo ê deve passar por todos os menus e fazer as
es olhas que est~ao indi adas nas guras dos apêndi es.
Feitas todas as es olhas, deve-se usar o bot~ao \Store Conguration to File" para
guardar uma opia da ongura ~ao em um arquivo om um nome ara tersti o, que
do umente a vers~ao do kernel, o autor da ompila ~ao, a data da ompila ~ao e quaisquer
outros dados relevantes. Em seguida se usa o bot~ao \Save and Exit" para es rever a
ongura ~ao de forma usavel pelo sistema de ompila ~ao.
Feito isto, vo ê pode ompilar o kernel e todos os modulos que foram ongurados,
ainda sem instalar nada, usando a sequên ia de omandos
make dep
make zImage
make modules
~ DO KERNEL
3.4. PROCEDIMENTO DE COMPILAC
AO
31
Cada um destes omandos pode levar algum tempo para ompletar. Fique de olho nos
vastos outputs que eles produzem e ertique-se de que eles s~ao ompletados sem erros.
Caso haja um erro, o omando make vai abortar a ompila ~ao e parar no ponto onde
houve o erro. Se isto a onte er anote as mensagens de erro que apare e. E extremamente
dif il que realmente haja algo errado om a ompila ~ao, todos os erros que a onte erem
devem ser onsequên ia da falta de algum elemento do ambiente de desenvolvimento
(mais provavel) ou de problemas de hardware no seu sistema (menos provavel). Tambem
e possvel que um erro seja onsequên ia de um onjuntos in onsistentes de op ~oes de
ongura ~ao mas, se vo ê seguir uidadosamente os exemplos dos apêndi es, isto n~ao
deve a onte er.
Estamos agora prontos para instalar o novo kernel, que residira no diretorio /boot/.
Assumindo que este seja o primeiro kernel desta vers~ao que vo ê ompila neste sistema,
oloque la o mapa de smbolos do kernel e o proprio kernel om os omandos
p -p System.map /boot/System.map-2.2.18
p -p ar h/i386/boot/zImage /boot/vmlinuz-2.2.18
onde estamos assumindo que vo ê ainda esteja no diretorio de ompila ~ao /usr/sr /linux/.
Note que o nome do kernel deve ser vmlinuz e n~ao vmlinux, indi ando que trata-se de um
kernel omprimido que se auto-des omprime no boot. Ainda sob as mesmas hipoteses,
vo ê pode agora instalar os modulos em seu lugar apropriado usando o omando
make modules_install
Isto ira riar um diretorio /lib/modules/2.2.18/ e olo ar todos os modulos que foram
ompilados em sub-diretorios apropriados dele.
Pronto, o novo kernel esta instalado no sistema, mas ele ainda n~ao e bootavel. Para
isto e ne essario rodar o omando lilo mas, antes disso, vamos veri ar que todos os
elementos est~ao em seus lugares. Na raiz do sistema deve haver soft links apontando
para dentro do diretorio /boot/, omo mostramos abaixo, num output do omando ls
-l /, editado para aber na pagina.
lrwxrwxrwx ......... System.map -> boot/System.map
drwxrwsr-x ......... boot
lrwxrwxrwx ......... vmlinuz -> boot/vmlinuz
Ja dentro do diretorio /boot/ devemos ter o que segue abaixo.

lrwxrwxrwx
-rw-r--r--rw-r--r-lrwxrwxrwx
-rw-r--r--rw-r--r-lrwxrwxrwx
.........
.........
.........
.........
.........
.........
.........
System.map -> System.map-2.2.18

System.map-2.2.17
System.map-2.2.18
vmlinuz -> vmlinuz-2.2.18
vmlinuz-2.2.17
vmlinuz-2.2.18
vmlinuz.old -> vmlinuz-2.2.17
32
Name Part Type FS Type

[Label Size (MB)
hda1 Primary Linux ext2 [/
128
hda2 Primary Linux swap
512
hda3 Primary Linux ext2 [/tmp
128
hda5 Logi al
Linux ext2 [/var
512
hda6 Logi al
Linux ext2 [/usr
5120
Tabela 3.1: Parti ionamento do dis o de sistema do front-end, de 6 GB. Os tamanhos das parti ~oes s~ao aproximados. Um KB signi a 1024 bytes e um MB signi a
10241024 bytes. A parti ~ao do lesystem /usr deve o upar tudo o que restar do dis o,
uma vez denidas as outras parti ~oes.
Mostramos aqui duas vers~oes diferentes do kernel instaladas no sistema, om os soft links
apontando para a mais re ente. Note que ha tambem um link de seguran a apontando
para a vers~ao anterior do kernel. Desde que ongura ~oes apropriadas sejam feitas no
sistema de boot \lilo", este soft-link pode ser usado para bootar a vers~ao antiga do
kernel, aso algo dê errado om o boot da nova vers~ao. Para atualizar estes soft links
dentro do diretorio /boot/ vo ê deve entrar nele e usar os omandos
ls -sf System.map-2.2.18 System.map
ls -sf vmlinuz-2.2.18 vmlinuz
ls -sf vmlinuz-2.2.17 vmlinuz.old
Desta forma o onteudo da raiz do sistema e mantido estavel, independente da vers~ao do

kernel que esta sendo usada, de forma que toda a ongura ~ao de boot reside dentro do
diretorio /boot/. Com tudo isto feito vo ê pode terminar a instala ~ao do novo kernel,
tornando-o bootavel, simplesmente rodando o omando
lilo
Observe que o que a abamos des rever e uma ompila ~ao e instala ~ao tpi a do kernel do
Linux, que vale para uma maquina generi a. Ela se apli a de forma exata ao front-end,
ao servidor e ao terminal, mas no aso dos nos, que v~ao bootar atraves da rede, havera
diferen as signi ativas no pro edimento, que in luira passos adi ionais.
3.5 Detalhes da Instala ~ao do Front-End

Alem das informa ~oes referentes a rede, durante a instala ~ao vo ê tera de fazer um
parti ionamento dos dis os do front-end. Siga o esquema de parti ionamento que se
vê na tabela 3.1, para um dis o de sistema de aproximadamente 6 GB. Olhe tambem
as imagens das janelas om o programa fdisk rodando em nosso prototipo, que se
en ontram no apêndi e E.1. Com esta estrategia de parti ionamento a sada do omando
df, uma vez terminada a instala ~ao, devera ser aproximadamente a que segue:
~ DO SERVIDOR
3.6. DETALHES DA INSTALAC
AO
Filesystem
/dev/hda1
/dev/hda3
/dev/hda5
/dev/hda6
1k-blo ks
126896
126896
507584
4927512
33
Used Available Use% Mounted on

29901
30265 25% /
56
60109
0% /tmp
80188
160494 16% /var
1571171
1699674 24% /usr
Terminada a instala ~ao da base do sistema, vo ê devera entrar omo root e instalar
uma serie de pa otes de software usando o omando apt-get install <pa ote>. Este
omando instala automati amente tanto o pa ote dis riminado quanto quaisquer outros
do qual ele dependa. Vo ê tera de instalar onjuntos de pa otes para varias nalidades
diferentes:
Ferramentas basi as: s~ao as ferramentas basi as que permitem que vo ê interaja om
o sistema; alguns dos prin ipais s~ao as shells e os editores de texto.
Ambiente de desenvolvimento: trata-se dos pre-pro essadores, ompiladores, assemblers, bibliote as de linkagem estati a e dinâmi a e editores de linkagem ne essarios
para podermos ompilar oisas.
Ambiente de rede: devem ser instalados tanto o liente quanto o daemon de ada um
dos varios proto olos de a esso: telnet, rlogin, rsh, ssh; devem ser instalados
tambem outros proto olos e omandos de rede, tais omo rwho, r p, et .
Servi os de rede: devem ser instalados daemons para os servi os de NFS, NTP e
NIS, in luindo os servidores deste ultimo; ada um destes servi os pre isa ser
ongurado, as re eitas para isto est~ao no apêndi e C, onde podem ser en ontrados
exemplos dos arquivos de ongura ~ao.
Utilitarios diversos: devem ser instaladas utilidades variadas para se lidar om arquivos, pro essos, disquetes, et .
Uma lista ompleta dos pa otes que devem estar instalados no front-end pode ser en ontrada no apêndi e C, mas sugere-se que vo ê instale os pa otes aos pou os, onforme
surgir a ne essidade de ada um, assim vo ê tera uma melhor han e de absorver a
fun ~ao de ada omponente deste onjunto de software. Depois disto, vo ê deve ompilar um kernel ustomizado para a sua maquina, para substituir o kernel generi o que
foi instalado pelo instalador da Debian. Para ongurar este kernel, olhe as listas de
menus de ongura ~ao que se en ontra no apêndi e E.3. Vai ser ne essario ongurar
no front-end os servi os de NIS.
3.6 Detalhes da Instala ~ao do Servidor

Durante a instala ~ao do servidor vo ê tambem tera de fazer um parti ionamento dos
dis os. Siga o esquema de parti ionamento que se vê nas tabelas 3.2 e 3.3, para dis os de
34

[Label Size (MB)
sda1 Primary Linux ext2 [/
128
sda2 Primary Linux swap
1024
sda3 Primary Linux ext2 [/tmp
128
sda5 Logi al
Linux ext2 [/var
1024
sda6 Logi al
Linux ext2 [/usr
7168
Tabela 3.2: Parti ionamento do dis o de sistema do servidor, de 9 GB. Os tamanhos das parti ~oes s~ao aproximados. Um KB signi a 1024 bytes e um MB signi a
Name Part Type FS Type [Label
Size (MB)
sdb1 Primary Linux ext2 [/pm
128
sdb3 Primary Linux ext2 [/pm /tmp
128
sdb5 Logi al
Linux ext2 [/pm /var
7168
sdb6 Logi al
Linux ext2 [/pm /usr
2048
Tabela 3.3: Parti ionamento do dis o de sistema dos nos, de 9 GB. Os tamanhos das parti ~oes s~ao aproximados. Um KB signi a 1024 bytes e um MB signi a 10241024 bytes.
A parti ~ao do lesystem /var deve o upar tudo o que restar do dis o, uma vez denidas
as outras parti ~oes.
sistema lo al e para os nos de aproximadamente 9 GB ada um. Olhe tambem as imagens
das janelas om o programa fdisk rodando em nosso prototipo, que se en ontram no
apêndi e E.1. Com esta estrategia de parti ionamento a sada do omando df, uma vez
terminada a instala ~ao, devera ser aproximadamente a que segue:
Filesystem
/dev/sda1
/dev/sda3
/dev/sda5
/dev/sda6
/dev/sdb1
/dev/sdb2
/dev/sdb3
/dev/sdb4
1k-blo ks
126895
126911
1014895
6351640
126895
126911
6351640
2038895

32372
87971 27% /
50
120308
0% /tmp
217943
744524 23% /var
3507004
2516701 58% /usr
18437
101906 15% /pm
50
120308
0% /pm /tmp
49912
1872335
3% /pm /var
354072
1569147 18% /pm /usr
Terminada a instala ~ao da base do sistema, vo ê devera entrar omo root e instalar
uma serie de pa otes de software usando o omando apt-get install <pa ote>. Vo ê
tera de instalar onjuntos de pa otes para varias nalidades diferentes:
~ DO TERMINAL
AO
35

[Label Size (MB)
hda1 Primary Linux ext2 [/
64
hda2 Primary Linux swap
256
hda3 Primary Linux ext2 [/tmp
64
hda5 Logi al
Linux ext2 [/var
256
hda6 Logi al
Linux ext2 [/usr
3584
Tabela 3.4: Parti ionamento do dis o de sistema do terminal,de 4 GB. Os tamanhos das parti ~oes s~ao aproximados. Um KB signi a 1024 bytes e um MB signi a
Ambiente de desenvolvimento: trata-se dos pre-pro essadores, ompiladores, assem-
blers, bibliote as de linkagem estati a e dinâmi a e editores de linkagem ne essarios

Servi os de rede: devem ser instalados daemons para os servi os de NFS, DHCP,
TFTP, NTP e NIS; ada um destes servi os pre isa ser ongurado, as re eitas
para isto est~ao no apêndi e C, onde podem ser en ontrados exemplos dos arquivos
de ongura ~ao.
Utilitarios diversos: devem ser instaladas utilidades variadas para se lidar om arqui-
vos, pro essos, disquetes, et ; alem disso, dever~ao ser instaladas algumas utilidades
espe as omo, por exemplo, as do sistema Etherboot.
Uma lista ompleta dos pa otes que devem estar instalados no servidor pode ser en ontrada no apêndi e C, mas sugere-se que vo ê instale os pa otes aos pou os, onforme
surgir a ne essidade de ada um. Depois disto, vo ê deve ompilar um kernel ustomizado para a sua maquina. Para ongurar este kernel, olhe as listas de menus de
ongura ~ao que se en ontra no apêndi e E.4.
3.7 Detalhes da Instala ~ao do Terminal

A instala ~ao do terminal e, de forma geral, pare ida om as front-end e do servidor.
Alem das informa ~oes referentes a rede, durante a instala ~ao vo ê tera de fazer um
parti ionamento do dis o do terminal. Siga o esquema de parti ionamento que se vê
na tabela 3.4, para um dis o de sistema de aproximadamente 4 GB. Olhe tambem
as imagens das janelas om o programa fdisk rodando em nosso prototipo, que se
36
en ontram no apêndi e E.1. Com esta estrategia de parti ionamento a sada do omando
df, uma vez terminada a instala ~ao, devera ser aproximadamente a que segue:
Filesystem
/dev/hda1
/dev/hda3
/dev/hda5
/dev/hda6
1k-blo ks
63448
63448
253792
3449259

29901
30265 50% /
56
60109
0% /tmp
80188
160494 33% /var
1571171
1699674 48% /usr
E laro que os onjuntos de pa otes a serem instalados s~ao um pou o diferentes, bem
omo o parti ionamento dos dis os, que e bem mais simples neste aso. Terminada
a instala ~ao da base do sistema, vo ê devera entrar omo root e instalar uma serie
de pa otes de software usando o omando apt-get install <pa ote>. Vo ê tera de
instalar onjuntos de pa otes para varias nalidades diferentes:
Ambiente de desenvolvimento: trata-se dos pre-pro essadores, ompiladores, assem-
blers, bibliote as de linkagem estati a e dinâmi a e editores de linkagem ne essarios

Servi os de rede: devem ser instalados daemons para os servi os de NFS, NTP e
NIS; ada um destes servi os pre isa ser ongurado, as re eitas para isto est~ao no
apêndi e C, onde podem ser en ontrados exemplos dos arquivos de ongura ~ao.
Utilitarios diversos: devem ser instaladas utilidades variadas para se lidar om arquivos, pro essos, disquetes, et .
Uma lista ompleta dos pa otes que devem estar instalados no terminal pode ser en ontrada no apêndi e C, mas sugere-se que vo ê instale os pa otes aos pou os, onforme
surgir a ne essidade de ada um. Depois disto, vo ê deve ompilar um kernel ustomizado para a sua maquina. Para ongurar este kernel, olhe as listas de menus de
ongura ~ao que se en ontra no apêndi e E.5.
Como o terminal vai dublar no papel do no virtual n0000, Ha algumas opera ~oes
adi ionais que e ne essario saber fazer nele, tais omo fazer um disquete de boot para o
no n0000, fazer um disquete de boot om uma imagem rom de boot remoto e es rever
uma imagem de boot remoto em um hip de eprom ou eeprom. As re eitas para estas
opera ~oes est~ao no apêndi e D.
~ DOS NOS

AO
37
3.8 Detalhes da Instala ~ao dos Nos

A instala ~ao dos nos e um pou o mais omplexa, devido ao fato que eles n~ao têm dis os
lo ais e todos os seus arquivos de sistema estar~ao lo alizados si amente no servidor.
Vamos usar o terminal no papel no no virtual n0000 e, depois de feita a sua instala ~ao,
vamos transferir o sistema deste no para o dis o do servidor que e dedi ado aos nos e,
em seguida, lonar todos os outros nos a partir dele. O pro edimento de instala ~ao neste
aso e o que segue:
1. Instale a base do sistema dos nos usando o terminal no papel do no virtual n0000.
A instala ~ao sera feita no dis o lo al do terminal, usando o mesmo parti ionamento
que sera usado depois para a instala ~ao do proprio terminal. Leve a instala ~ao
ate o nal e ertique-se de que ela esta ompleta. Cada opera ~ao que vo ê n~ao
zer neste momento tera de ser feita om N repeti ~oes depois, onde N e o numero
de nos que vo ê ira instalar. Os onjuntos de pa otes a serem instalados tambem
s~ao um pou o diferentes neste aso. Terminada a instala ~ao da base do sistema,
vo ê devera entrar omo root e instalar uma serie de pa otes de software usando o
omando apt-get install <pa ote>. Vo ê tera de instalar onjuntos de pa otes
para varias nalidades diferentes:
Ferramentas basi as: s~ao as ferramentas basi as que permitem que vo ê inte-
raja om o sistema; alguns dos prin ipais s~ao as shells e os editores de texto.
Ambiente de desenvolvimento: trata-se dos pre-pro essadores, ompiladores,
assemblers, bibliote as de linkagem estati a e dinâmi a e editores de linkagem
ne essarios para podermos ompilar oisas.
Ambiente de rede: devem ser instalados tanto o liente quanto o daemon de
ada um dos varios proto olos de a esso: telnet, rlogin, rsh, ssh; devem
ser instalados tambem outros proto olos e omandos de rede, tais omo rwho,
r p, et .
Servi os de rede: devem ser instalados daemons para os servi os de NTP e NIS;
ada um destes servi os pre isa ser ongurado, as re eitas para isto est~ao
no apêndi e C, onde podem ser en ontrados exemplos dos arquivos de ongura ~ao.
Utilitarios diversos: devem ser instaladas utilidades variadas para se lidar om
arquivos, pro essos, disquetes, et .
Uma lista ompleta dos pa otes que devem estar instalados nos nos pode ser
en ontrada no apêndi e C, mas sugere-se que vo ê instale os pa otes aos pou os,
onforme surgir a ne essidade de ada um. Depois disto, vo ê deve ompilar um
kernel ustomizado para os seus nos. Para ongurar este kernel, olhe as listas
de menus de ongura ~ao que se en ontra no apêndi e E.6. Ao ontrario do que
38
a onte e nos outros sistemas, a instala ~ao nal deste kernel sera feita no servidor,
n~ao nos nos, omo veremos mais adiante. Desde que todas as maquinas usem
CPUs de mesma arquitetura, omo e o aso aqui, a propria ompila ~ao tambem
pode ser feita no servidor. Tambem sera feita no servidor a onvers~ao deste kernel
em kernels bootaveis pela rede, um para ada no, pro edimento este uja re eita
esta no apêndi e D. Uma vez terminada a instala ~ao do no n0000, e ne essario
realizar a sequên ia adi ional de tarefas que segue.
2. Fa a arquivos tar de ada um dos lesystems do no n0000, transferindo em seguida
ada arquivo para o lesystem /usr do servidor, usando em ada aso um dos
omandos que seguem:
tar
tar
tar
tar
-C / - pzlvf /usr/root.tgz .
-C /tmp - pzlvf /usr/tmp.tgz .
-C /var - pzlvf /usr/var.tgz .
--ex lude usr.tgz -C /usr - pzlvf /usr/usr.tgz .
Antes de fazer o arquivo tar do lesystem /usr, ertique-se de que vo ê ja transferiu os outros arquivos tar para o servidor e os retirou do lesystem /usr lo al.
A transferên ia pode ser feita por FTP ou por NFS. Durante a es rita destes arquivos o sistema do terminal deve estar em modo \single-user", de tal forma que
os lesystems estejam quies entes.
3. No servidor, parti ione e rie lesystems no dis o que vai ser reservado para os
nos. Esta e uma opera ~ao padr~ao, envolvendo os omandos fdisk e mke2fs, a
menos do fato de que no lesystem /pm /, que sera usado omo raiz dos nos, bem
omo no lesystem /pm /var, que sera usado omo /var/ dos nos, sera riado
no futuro um numero maior do que o usual de hard links. Em espe ial na raiz,
este numero sera muito maior que o usual, podendo hegar a esgotar o numero de
inodes disponveis no lesystem.
Assim, e importante que estes lesystems sejam bem folgados em termos de espa o,
alem do que sera ne essario formata-los om alguns parâmetros n~ao-usuais de
forma a aumentar o numero de inodes disponveis. No aso do /pm / sugerimos
que o numero de inodes seja elevado para o maximo possvel, para o que deve-se
riar o lesystem om o omando
mke2fs -i 1024 -s 1 /dev/sd<dispositivo-apropriado>
Isto faz om que o lesystem tenha er a de quatro vezes mais inodes do que e
usual. No aso do /pm /var/ nem sempre e ne essario aumentar o numero de
inodes, pois em geral ha um numero menor de arquivos grandes la. Caso vo ê
queira se erti ar de n~ao ter problemas no futuro, utilize o omando na forma
~ DOS NOS

AO
39
mke2fs -i 2048 -s 1 /dev/sd<dispositivo-apropriado>
4. No servidor, abra ada arquivo tar em um diretorio apropriado nos lesystems do

dis o que esta reservado par aos nos, usando em ada aso o omando apropriado:
tar
tar
tar
tar
-C
-C
-C
-C
/pm /0000 -xpzvf /usr/root.tgz

/pm /tmp/0000 -xpzlvf /usr/tmp.tgz
/pm /var/0000 -xpzlvf /usr/var.tgz
/pm /usr -xpzlvf /usr/usr.tgz
Vo ê deve riar os diretorios 0000/ antes de abrir ada arquivo tar. Verique as
autoriza ~oes do diretorio /pm /tmp/0000. Se elas n~ao estiverem exatamente iguais
as do diretorio /tmp, orrija-as.
5. Crie diretorios 0001, 0002, et , orrespondentes aos diretorios 0000 que vo ê riou a ima, um para ada no que vo ê vai instalar. Em seguida vo ê ira opiar
re ursivamente o onteudo de ada diretorio 0000 em ada um dos diretorios orrespondentes 0001, et . Para fazer isto vo ê usara pipelines de omandos tar,
omo mostra o exemplo abaixo:
tar -C /pm /0000 - pf - . | tar -C /pm /0001 -xpvf tar -C /pm /tmp/0000 - pf - . | tar -C /pm /tmp/0001 -xpvf tar -C /pm /var/0000 - pf - . | tar -C /pm /var/0001 -xpvf -
Fa a isto para os lesystems /, /tmp e /var de ada um dos nos. Observe que para
o lesystem /usr n~ao e ne essario fazer opias omo estas, pois este lesystem sera
ompartilhado por todos os nos.
6. Entre no diretorio /et de ada no (/pm /0001/et e assim por diante) e use seu
editor de texto predileto (o ema s) para modi ar os seguintes arquivos de ongura ~ao, que determina a identidade de ada no: network/interfa es, hostname
fstab e mailname, aso exista. Exemplos destes arquivos de ongura ~ao podem
ser en ontrados no apêndi e C.
7. Coloque em /pm uma opia exe utavel do s ript de nome
hard-link- ommon-files-root
que pode ser en ontrado no apêndi e C, fazendo nele ajustes para re etir o numero
de nos que vo ê tem. Va para o diretorio /pm e rode este s ript, que vai identi ar
e fazer \hard links" apontando para o diretorio 0000 para arquivos idênti os em
40
ada um dos diretorios 0001, et . Com isto, redundân ias de onteudo ser~ao
eliminadas e uma onsideravel quantidade de espa o em dis o sera e onomizada,
permitindo que se instale um grande numero de nos em um dis o de dimens~oes
limitadas. Sempre que vo ê adi ionar nos ao seu luster ou zer algum upgrade
de sistema nos nos, deve rodar este s ript.
8. Coloque em /pm /var uma opia exe utavel do s ript de nome
hard-link- ommon-files-var
que pode ser en ontrado no apêndi e C, fazendo nele ajustes para re etir o numero
de nos que vo ê tem. Va para o diretorio /pm /var e rode este s ript, que vai
identi ar e fazer \hard links" de forma analoga ao que vo ê ja fez em /pm .
Uma vez instalado e bootado o no, o output do omando df, mostrando os lesystems
de sistema montados atraves de NFS a partir do servidor, deve ser omo o exemplo que
mostramos logo abaixo. E laro que, alem destes, havera tambem o lesystem de home
dos usuarios.
Filesystem
1k-blo ks
s01:/pm /0001
126895
s01:/pm /tmp/0001
126911
s01:/pm /var/0001
2026899
s01:/pm /usr
2027923

18437
101906 15% /
54
120304
0% /tmp
51437
1870810
3% /var
354072
1569147 18% /usr
3.9 Detalhes da Instala ~ao da Rede

N~ao ha nenhuma instala ~ao de software a ser realizada nos equipamentos de rede em
si, todas as ongura ~oes de rede s~ao denidas nas diversas outras maquinas que est~ao
ligadas a eles. A uni a maquina que vai ser ongurada na rede lo al de sua institui ~ao
e o front-end. Como ja foi expli ado anteriormente, vo ê tera de obter do gerente desta
LAN um endere o e as informa ~oes ne essarias para a instala ~ao nela desta maquina.
A instala ~ao de todas as maquinas na rede privada do seu PMC e uma atividade que
vo ê tera de fazer de forma autônoma, tomando todas as de is~oes ne essarias sobre a
distribui ~ao de endere os e sobre a ongura ~ao da rede.
Uma rede privada e uma rede que n~ao tem onex~ao direta om a Internet e que
utiliza uma ole ~ao espe ial de endere os IP, reservados na Internet para este m, O
\range" de endere os reservados para redes privadas e a ole ~ao de endere os dados
por 192.168.X.Y, onde X e Y s~ao quaisquer numeros de 0 a 255. Com isto temos uma
ole ~ao de er a de 65000 endere os que podem ser utilizados dentro da rede privada,
mais do que o su iente, portanto, por maior que seja o PMC que va ser montado. E
possvel limitar este onjunto de endere os a uma sub-rede menor, por exemplo de 256
endere os. Aqui esta um exemplo de ongura ~ao de uma rede privada de lasse C:
~ DA REDE
AO
range de endere os:

mas ara (netmask):
41
192.168.10.0{192.168.10.255
192.168.10.0
255.255.255.0
192.168.10.255
192.168.10.1
Ja uma rede privada ompleta, de lasse B, seria ongurada assim:

range de endere os:
mas ara (netmask):
192.168.0.0{192.168.255.255
192.168.0.0
255.255.0.0
192.168.255.255
192.168.0.1
Como se vê, alguns endere os s~ao reservados e têm um tratamento espe ial. Aqui esta
a expli a ~ao detalhada do papel de ada um destes parâmetros:
network: trata-se do primeiro endere o do range, que e reservado para indi ar uma
referên ia a sub-rede omo um todo. Este endere o n~ao deve ser atribudo a
nenhuma maquina individual.
netmask: trata-se de um onjunto de 1's seguido de um onjunto de 0's, perfazendo
32 bits. A parte da mas ara ontendo 1's indi a a parte omum de todos os
endere os desta sub-rede, indi ando a parte do endere amento que representa a
rede omo um todo; a parte da mas ara ontendo 0's indi a a parte que e diferente
para ada endere o desta sub-rede, indi ando a parte do endere amento que se
refere aos hosts dentro da sub-rede.
broad ast: trata-se do ultimo endere o do range, que e reservado para indi ar uma
referên ia a todos os hosts da sub-rede. Um pa ote enviado para este endere o
sera re ebido e lido por todos os hosts da sub-rede. Este endere o n~ao deve ser
atribudo a nenhuma maquina individual.
gateway: trata-se aqui do endere o de um dos hosts da sub-rede, que vai servir omo
gateway para a omuni a ~ao om o resto da Internet. E tradi ional, mas n~ao
ne essario, reservar o endere o 1 para este m. Em nosso aso este endere o sera
atribudo ao front-end.
Observe que a estrutura logi a da ongura ~ao de uma rede privada e idênti a as ongura ~oes da Internet. A rede ser privada signi a que o gateway n~ao vai fazer roteamento
de pa otes originarios da rede privada diretamente para a Internet. Pa otes om endere o de origem neste range n~ao podem trafegar na Internet. Por outro lado o front-end
pode ler o onteudo de pa otes da rede privada e transmitir este onteudo para a Internet dentro de seus proprios pa otes, pois ele tem um endere o legal para trafego na
42
Internet: o endere o da rede lo al da sua institui ~ao que vo ê obteve do gerente daquela
rede lo al. Assim, e possvel o trafego de informa ~ao entre os nos e quaisquer hosts da
Internet, desde que ela seja feito de forma expl ita atraves do front-end.
Outro aspe to que em geral esta envolvido na ongura ~ao de uma rede e a quest~ao
de denir o roteamento de pa otes. A maior parte das sub-redes da Internet usa um
tipo simples de roteamento para fora da rede lo al, que e uma roda default apontando
para o gateway. Este, por sua vez, deve ter regras de roteamento denidas de tal forma
que os hosts da sub-rede possam tro ar pa otes om hosts de fora dela. Assim, a menos
do gateway ada host de sua subrede pre isa saber apenas duas regras bem basi as de
roteamento:
1. Se um pa ote deve ser enviado para um host da rede lo al (o que e determinado
om o uso da netmask), o pa ote deve ser endere ado diretamente para aquele
host e enviado atraves da pla a de rede da maquina.
2. Se um pa ote deve ser enviado para um host que n~ao e da rede lo al, o pa ote
deve ser endere ado de fato para o gateway (que e um host da rede lo al), ao qual
e enviado, mais uma vez, atraves da pla a de rede da maquina.
O sistema Linux implementa de forma automati a estas duas regras, de forma que
vo ê n~ao pre isa fazer nada a respeito. Quanto ao front-end, que tem duas pla as
de rede e portanto e de fato um roteador, em prin pio seriam ne essarias regras que
determinando quando um pa ote deve ser enviado para uma ou para a outra. Mas isto so
seria ne essario se pa otes da rede privada fossem trafegar diretamente para a Internet,
o que n~ao deve a onte er, de forma que n~ao ha, de fato, nenhuma regra de roteamento
a ser implementada e vo ê n~ao pre isa se preo upar om isto.
Ha outras preo upa ~oes om ongura ~oes de rede omo, por exemplo, o fato de
que os lesystems de sistema dos nos devem ser montados por eles sem a ativa ~ao do
me anismo de \lo king" do NFS. Isto estara re etido nos arquivos de ongura ~ao (neste
aso atraves de uma op ~ao de montagen no arquivo /et /fstab) que vo ê vai es rever
em ada uma das maquinas, baseando-se nos exemplos que podem ser en ontrados no
apêndi e C. Assim, n~ao e ne essario entrarmos em muitos detalhes neste momento.
Captulo 4
Opera ~ao
4.1 Uso do Sistema pelos Usuarios
O uso do sistema pelos seus usuarios deve se pro essar da seguinte forma: o usuario
a essa o front-end atraves da rede; omo o seu home de origem esta montado no frontend, ele tem a esso a todos os seus arquivos e a sua ongura ~ao de ambiente de trabalho
e importada de seu sistema de origem. Havendo ne essidade de arquivos lo ais de apoio
a ongura ~ao de ambiente de trabalho dos usuarios, eles ser~ao instalados no front-end,
tipi amente no diretorio /usr/lo al/, sendo distribudos para os servidor atraves de
uma estrutura de make no front-end. Uma vez olo ados no servidor, estes arquivos
estar~ao disponveis tambem nos nos. Uma vez no front-end o usuario pode desenvolver
o seu programa, se ja n~ao tiver feito isto em seu sistema de origem, ou submeter jobs
aos nos de pro essamento, seja entrando neles interativamente, seja atraves de rsh, seja
atraves do uso de programas que utilizem o sistema PVM. Os nos de pro essamento
es revem os arquivos que ontem a sada do programa diretamente na onta do usuario,
ou enviam mensagens de PVM para o front-end, que es reve os arquivos. Desta forma
os dados s~ao retornados automati amente ao sistema de home original do usuario.
Observe que usuarios de varios sistemas home diferentes na rede lo al da institui ~ao
podem utilizar o luster de pro essamento paralelo desta forma. Para permitir isto,
e ne essario que haja na institui ~ao um esquema universal, respeitado em todos os
sistemas, de atribui ~ao de numeros de usuario, de tal forma que ada usuario tenha
um numero proprio, diferente de todos os outros. Note-se que o front-end n~ao fun iona
omo home de nenhum dos usuarios, o administrador do front-end n~ao tem nenhuma
responsabilidade administrativa ou opera ional sobre os homes. Ou seja, o front-end e
territorio neutro no que diz respeito aos diversos grupos que o utilizem. N~ao ha nada
em seus dis os lo ais que seja propriedade de algum usuario ou grupo. Alem disso, ele
n~ao exe uta servi os de arater geral, tais omo orreio eletrôni o, para nenhum usuario
em parti ular. Trata-se aqui de um sistema fo alizado num determinado tipo de tarefa.
A organiza ~ao do uso simultâneo do PMC por varios usuarios pode ser feita de varias
43
44
~
CAPITULO 4. OPERAC
AO
formas diferentes. A n~ao ser em sistemas muito grandes, om um numero muito grande
de usuarios, e muito provavel que os usuarios estejam usando o sistema predominantemente em epo as diferentes. Quando este n~ao for o aso, e possvel que ada usuario use
um determinado sub- onjunto dos nos, o que pode ser feito a m~ao ou atraves dos arquivos pessoais de ongura ~ao do PVM ou do MPI nas ontas de ada usuario, sempre
mediante a ordo entre os usuarios. A s vezes pode ser vantajoso que dois usuarios usem
simultaneamente o mesmo onjunto de nos pois, desta forma, se o pro esso de um dos
usuarios em um determinado no parar a espera de uma mensagem, o no ainda podera
estar pro essando o programa do outro usuario. Tambem e possvel rodar o sistema
NQS no PMV, denindo desta forma varias las om prioridades diferentes.
Alem disso, e possvel limitar o tempo maximo de CPU que ada usuario pode usar
em ada no, bem omo a quantidade maxima de memoria RAM que ada pro esso pode
usar, atraves do sistema PAM do Linux. A limita ~ao do uso de memoria e uma boa ideia
em quaisquer ir unstân ias, dado o fato de que n~ao ha possibilidade de swap nos nos,
de forma que a memoria virtual disponvel esta limitada a quantidade de memoria real
existente. Provavelmente a melhor forma de a omodar usuarios simultâneos e atraves
da divis~ao dos nos existentes entre eles. Quando ne essario, e possvel limitar o a esso
de ada usuarios a ada no om o uso do sistema de TCP wrappers, implementado pelo
daemon t pd, que e mais omumente usado por motivos de seguran a, estando de fato
ativado por default na distribui ~ao Debian do Linux. Para aprender omo fazer isto
veja a pagina de manual hosts a ess. Outra possibilidade e a deni ~ao de grupos de
usuarios atraves da estrutura de netgroups do sistema NIS.
A n~ao ser em sistemas muito grandes, om um grande numero de usuarios que s~ao
essen ialmente anônimos uns em rela ~ao aos outros, a melhor estrategia de organiza ~ao e
sempre a de estabele er e manter o dialogo entre os usuarios. Em sistemas muito grandes
pode ser ne essario denir grupos de usuarios e dar a ada grupo a esso a apenas parte
da maquina. Entretanto, este e um tipo de ompli a ~ao que deve ser evitado sempre que
for possvel, pois representam um onsideravel aumento no trabalho de geren iamento
do sistema.
4.2 Geren iamento e Administra ~ao

A opera ~ao de um luster do tipo PMC e muito simples, pois a maior parte dos seus
sistemas e prati amente destituda de qualquer ne essidade de manuten ~ao. Os logs do
sistema s~ao i lados automati amente, e raro que seja ne essario fazer upgrades muito
extensos dos sistemas, n~ao ha geren iamento de espa o em dis o para usuarios a ser
feito, nem e ne essario realizar manuten ~ao de ongura ~oes de ambiente de usuarios.
~
4.2. GERENCIAMENTO E ADMINISTRAC
AO
45
4.2.1 Rotinas Administrativas
Alem dos upgrades rotineiros de kernel e de distribui ~ao, as tarefas administrativas

rotineiras do gerente de um sistema deste tipo se restringem a abertura no servidor
de ontas para os usuarios e a ontatos om os administradores dos sistemas de home
dos usuarios, para soli itar a autoriza ~ao de exporta ~ao dos homes para o front-end,
seguida da montagem destes homes no front-end. Esporadi amente algum software tera
de ser instalado nos sistemas, em geral atraves da simples abertura de um ou mais
pa otes. Pode ser ne essario obter dos sistemas de origem dos usuarios e instalar no
front-end arquivos de ongura ~ao entralizada de ambiente de trabalho dos usuarios,
a serem olo ados no diretorio /usr/lo al/. Para distribu-los para o servidor e para
os nos a melhor alternativa e usar uma estrutura de make, om a qual e simples mantêlos atualizados. Na prati a a distribui ~ao deve ser feita apenas para o servidor, uma
vez que e nele que est~ao os dis os dos nos, devendo ser dirigida para /usr/lo al/ e
/pm /usr/lo al/.
Uma vez que os nos, o terminal e o servidor est~ao numa rede privada, que n~ao pode
ser a essada diretamente a partir da Internet, as preo upa ~oes de seguran a relativas
a possveis invas~oes pela rede se limitam ao front-end. Alem disso, observe-se que n~ao
se trata aqui de um onjunto de maquinas de uso geral de uma grande omunidade
de usuarios anônimos, de forma que problemas de dis iplina interna destes usuarios
n~ao s~ao uma preo upa ~ao. Em suma, basta fazer no front-end as atualiza ~oes de seguran a do software existente para que os problemas de seguran a de todo o sistema
estejam sob ontrole. Sugere-se que se ongure no programa apt-get do front-end o
site se urity.debian.org ou um espelho do mesmo, de forma que baste rodar de vez
em quando o par de omandos
apt-get update
apt-get -fu upgrade
para se olo ar a seguran a do sistema em dia. Alem disso, e muito fa il proteger e
ontrolar o a esso ao front-end om o uso do programa t pd, o TCP wrapper. Como
em geral esta maquina n~ao forne e servi os de qualquer tipo para fora da rede lo al,
o a esso a ela pode ser restrito a esta rede lo al, o que torna as oisas muito mais
fa eis e seguras para o administrador. Eventuais usuarios de fora da rede lo al podem
ser autorizados individualmente, omo parte de uma losoa de a esso do tipo \mostly
losed" implementada atraves do t pd, veja para isto a pagina de manual hosts a ess.
Exemplos dos arquivos de ongura ~ao do t pd podem ser en ontrados no apêndi e C.
Uma ex e ~ao a este losoa de a esso pode ser o a esso a um servidor Apa he de
paginas de WWW que seja instalado no front-end. Este tipo de a esso deve permane er
o mais aberto possvel, mas isto n~ao representa problema pois e um tipo de a esso
basi amente read-only, pou o propenso a problemas de seguran a. A instala ~ao de um
servidor Apa he no front-end pode ser uma boa ideia omo parte de um me anismo de
oordena ~ao do uso ooperativo de varios sistemas PMC espalhados pela rede.
46
~
CAPITULO 4. OPERAC
AO
4.2.2 Instala ~ao de Novos Nos

Uma oisa que pode ter de ser feita de vez em quando e a adi ~ao de novos nos ao
sistema, a arretando a ne essidade de realizar a sua montagem e posterior instala ~ao.
A montagem do hardware e simples e deve ser feita segundo as orienta ~oes dadas no
aptulo 2. Na verdade, toda a instala ~ao posterior de um no em um sistema ja existente
e uma opera ~ao prati amente idênti a a instala ~ao ini ial dos nos. Para se fazer isto n~ao
e ne essario desligar ou rebootar qualquer outra maquina do sistema ex eto o terminal.
Para fazer a ongura ~ao do setup da nova motherboard, a ideia e usar o terminal,
ou alguns omponentes dele tais omo o monitor, a pla a de vdeo e o te lado. O a erto
da nova pla a de rede 3C905B, se ne essario, tambem deve ser feito no terminal, segundo
a re eita que se en ontra no apêndi e A. Outra oisa que deve ser feita no terminal e a
grava ~ao de mais um hip de boot, para a nova pla a de rede.
A instala ~ao do software de um novo no onsiste de simplesmente fazer mais uma
opia do no virtual n0000, onforme esta expli ado na se ~ao 3.8. Depois de fazer a
opia e de editar os pou os arquivos que denem a identidade do novo no, n~ao se
esque a de fazer os updates orrespondentes nos s ripts hard-link- ommon-files-root
e hard-link- ommon-files-var e de roda-los para diminuir a taxa de o upa ~ao dos
dis os.
Alem disso, vo ê tera de a res entar o no nos varios arquivos que ontêm a lista
ompleta deles (hosts, hosts.equiv, et ) e tera de ongurar o novo no no sistema
DHCP do servidor de dis os. Finalmente, aso esteja usando o esquema de um kernel
diferente para ada no, vo ê devera fazer o update do s ript make-netboot-kernels e
roda-lo para produzir mais um kernel de boot pela rede. Isto feito, e olo ar o no em seu
lugar e liga-lo. Vo ê talvez queira monitorar o seu primeiro boot a partir do terminal,
usando o onsole serial.
4.2.3 Monitoramento dos Nos

O monitoramento rotineiro do uso e da opera ~ao dos nos pode ser feito de varias maneiras. O omando ruptime pode ser usado para veri ar a arga sobre todos os nos.
E laro que, para quer isto fun ione, e ne essario ter o daemon rwhod rodando em todo
os sistemas. Como os nos est~ao na rede privada, e ne essario rodar este omando no
front-end, no servidor de dis os ou no terminal. Os sistemas PVM e MPI de passagem
de mensagens têm os seu proprio programa de monitoramento, hamados xpvm e xmpi,
que permitem o monitoramento da atividade dos nos em um determinado programa.
Para identi ar os programas que est~ao rodando de forma intensiva em ada nos, bem
omo os respe tivos usuarios, pode-se usar um s ript que use rsh, omo o s ript njobs
que pode ser en ontrado no apêndi e C.
Alem do uso do onsole serial, que se destina mais ao tratamento de nos que venham
a ter problemas, o monitoramento rotineiro dos nos durante o boot tambem pode ser
feito atraves do uso do led de beep. Isto fun iona desde que n~ao esteja sendo usado
~
4.2. GERENCIAMENTO E ADMINISTRAC
AO
47
o kernel om onsole pela porta serial, pois neste aso os sinais de \beep" v~ao para a
porta serial, de forma a fazerem beepar um terminal que esteja ligado a ela. Em primeiro
lugar, o led de beep a ende mais longamente durante a i lagem de hardware quando
se reseta a maquina. Trata-se do protesto do hardware por n~ao en ontrar na maquina
um monitor e um te lado. Depois disto, e possvel in luir nos s ripts de ini ializa ~ao do
sistema pequenos programas que fa am o led pis ar um determinado numero de vezes.
Por exemplo, temos um pequeno s ript olo ado em /et /r .boot/beep3 que faz o
led pis ar três vezes quando o sistema termina de entrar em modo single-user. Depois
disto um outro s ript olo ado em /et /init.d/beep5 faz o led pis ar in o vezes
quando o sistema termina de entrar em modo multi-user e torna-se disponvel para os
usuarios. Para isto, basta olo ar um link apontando para ele no diretorio /et /r 2.d/
do no, que orresponde ao modo multi-user:
lrwxrwxrwx ......... /et /r 2.d/S98beep5 -> ../init.d/beep5
Copias destes s ripts podem ser en ontradas no apêndi e C. Alem disso, enviar um sinal
de beep para um no pode ser uma forma fa il de se identi ar um no em meio a todos
os outros. Pode-se fazer isto simplesmente om o omando e ho na linha de omando,
exatamente da forma omo ele e usado nestes s ripts.
O monitoramento dos nos tambem pode ser feito pelo x onsole rodando no terminal. Isto e onveniente pois pode-se monitorar todo o onjunto de forma ontnua. E
fa il es rever um s ript de shell para abrir pro essos de x onsole para todos os nos,
usando para isto o terminal. Vo ê pode ate ter dois sistemas X11 independentes rodando no terminal, um dos quais dedi ado a esta fun ~ao e o outro usado para as fun ~oes
gerais do terminal. Com o uso do sistema de desktops virtuais do sistema do window
manager fvwm, prati amente n~ao ha limite para o numero de programas x onsole que
podem estar rodando ao mesmo tempo e, portanto, para o numero de nos que se pode
monitorar desta forma. Alguns exemplos de s ripts deste tipo podem ser en ontrados
no apêndi e C.
4.2.4 Problemas om um dos Nos

Em aso de surgirem problemas om um no, a primeira providên ia e monitorar o seu
boot atraves do onsole serial. Veja as instru ~oes de omo fazer isto na se ~ao D.3.1. Na
se ~ao E.2 pode-se ver imagens mostrando o onsole serial em uso. Se n~ao for possvel
entrar pela rede ou pelo onsole serial para dar um shutdown organizado no sistema
do no, e sempre possvel usar o bot~ao de reset que esta soldado a motherboard do no.
Apesar de que e melhor evitar isto se possvel, o uso do bot~ao de reset em geral n~ao
tem onsequên ias serias em um sistema que n~ao tem dis os lo ais. A monitora ~ao dos
a onte imentos durante o boot atraves do led de beep tambem podera ser util.
Para que se possa fazer uso do onsole serial, e ne essario que o kernel que esta
rodando no no esteja usando a porta serial omo onsole. Isto pode ser feito om a
48
~
CAPITULO 4. OPERAC
AO
mudan a do kernel de boot ou om mudan as adequadas no arquivo de ongura ~ao do

sistema DHCP. Lembre-se de que vo ê n~ao so pode fazer um login no no pelo onsole
serial, omo pode rebootar a maquina atraves dele! E laro que a ombina ~ao de te las
usada para isto normalmente, o famoso [Ctrl-[Alt-[Del, n~ao vai fun ionar, alias,
uidado para n~ao rebootar desta forma, em vez do no, a maquina onde vo ê esta rodando
a janela do onsole serial! Vo ê deve entrar omo root e usar o omando shutdown
expli itamente. Fazendo isto vo ê vera pelo onsole o sistema air e voltar normalmente.
E laro que a parte de i lagem do setup que apare eria num onsole VGA estara
faltando, mas vo ê vera tudo que a onte e om o kernel e om o sistema.
Em geral um problema om um no, o que deve a onte er muito raramente, sera
devido a algum problema om algum elemento de software e no maximo sera ne essario
rebootar aquele no. Em termos de hardware, a oisa mais provavel e que haja um
problema om a memoria RAM, neste aso usar o programa memtest do Linux, que
faz o teste da memoria, pode ser muito util. Sugere-se entrar no no pelo onsole serial,
olo ar a maquina em modo single-user om o omando shutdown e rodar o omando
om parâmetros que testem de uma vez quase toda a memoria, deixando apenas uma
folga de uns 8 MB, de tal forma que o programa rode mais rapido. Se o teste apontar
problemas om a memoria, tente retirar os DIMMs, limpar os ontatos do slot e dos
DIMMs om um spray limpa- ontatos e fazer o teste de novo. Se realmente houver
algum problema om algum DIMM, a uni a sada e tro a-lo por um novo.
E muito dif il que a onte a algo om o pro essador ou mesmo om a pla a de rede.
No aso de suspeita de problemas om a pla a de rede, verique se ela esta bem assentada
em seu slot e, se ne essario, retire-a e aproveite para limpar os ontatos do slot e da
pla a om um spray limpa- ontatos antes de re olo ar a pla a. Verique tambem se os
abos de rede est~ao bem olo ados e se n~ao est~ao dani ados. No aso do pro essador
o mesmo tipo de uidado na limpeza dos ontatos pode ajudar. Verique tambem se a
ventoinha do dissipador esta operando orretamente, se ela n~ao esta entupida de poeira
e se o dissipador esta olo ado orretamente no CPU, om pasta termi a na regi~ao de
ontato entre os dois. Nun a vimos um CPU realmente pifar por aqui, mas se isto algum
dia a onte er, vo ê tera de tro a-lo por um novo.
Pode ser uma boa ideia vo ê ter uma ou duas pla as de rede e três ou quatro DIMMs
de memoria RAM na prateleira para uso imediato em aso de alguma quebra. Tambem
e uma boa ideia ter uma ou duas fontes de alimenta ~ao sobressalentes para os nos.
4.3 Upgrades de Sistema

4.3.1 Upgrade do Kernel
As atualiza ~oes do kernel em geral onsistir~ao de bug-xes que tornam sua opera ~ao mais
estavel e onavel, de forma que e sempre uma boa ideia manter os kernels atualizados
dentro de uma \major version". Ja a mudan a para uma nova major version, ou seja,
4.3. UPGRADES DE SISTEMA
49
uma nova vers~ao do Linux om novas apa idades, pode ser bem mais problemati a e
deve ser feita om prudên ia e apenas se a nova vers~ao tiver novas propriedades que
sejam desejaveis para o luster, ou quando a nova vers~ao estiver bem madura e a velha
deixar de ser desenvolvida no sentido de trabalho em bug-xes.
A major version do Linux e ara terizada pelos dois primeiros numeros do numero da
vers~ao, enquanto o nvel de bug-x e determinado pelo ter eiro numero. Por exemplo,
neste momento a major version esta passando de 2.2 para 2.4, pois esta a aba de ser
lan ada. A vers~ao 2.2 esta no nvel de bug-x 2.2.18, enquanto a nova vers~ao esta em
2.4.0. A instala ~ao de um novo kernel da mesma vers~ao prin ipal deve ser feita toda
vez que um deles e lan ado. A rotina de ompila ~ao e instala ~ao e a mesma que ja foi
des rita antes no se ~ao 3.4.
4.3.2 Upgrade da Debian

A atualiza ~ao da distribui ~ao Debian e importante devido ao fato de que estas atualiza ~oes frequentemente abordam problemas relativos a seguran a em todos os softwares.
Assim omo no aso do kernel, temos aqui uma diferen ia ~ao entre \major version"
e \updates", mas om uma organiza ~ao um pou o diferente. No momento estamos
na vers~ao 2.2 da Debian, ujo nome e \potato", enquanto a vers~ao anterior, a 2.1,
hamava-se \slink". A proxima vers~ao esta em desenvolvimento e tera numero 2.3 e
nome \woody". No momento, todos os equipamentos de nosso grupo de pesquisa est~ao
fun ionando de forma estavel om a potato.
No aso da distribui ~ao ha dois me anismos de \update" dentro de uma determinada vers~ao. Primeiro, de vez em quando s~ao feitos \releases" novos, basi amente om
updates de seguran a e bug xes, no momento estamos na 2.2r2. Alem disso, ha um
site, ujo endere o e
ftp://se urity.debian.org/
que faz o release imediato de quaisquer pa otes que tenham tido bug-xes de seguran a, permitindo assim que vo ê mantenha, de forma simples e rapida, a seguran a
do seu sistema em dia, atraves do uso do programa apt-get, que automatiza de forma
extraordinaria a instala ~ao e o upgrade dos pa otes de software da Debian.
De fato, e este programa que vo ê ira usar rotineiramente para instalar pa otes, seja
na instala ~ao ini ial da maquina, seja nos upgrades periodi os. Para que vo ê tenha os
upgrades de seguran a da sua maquina, e bom rodar o apt-get om alguma frequên ia,
digamos uma vez por semana. Vo ê pode manter-se informado sobre mudan as na
Debian, bem omo sobre a existên ia de upgrades de seguran a, visitando de vez em
quando a home page do projeto ou adastrando-se em uma das muitas listas que existem.
Ambas as oisas pode ser feitas atraves da home page, ujo endere o e
http://www.debian.org/
50
~
CAPITULO 4. OPERAC
AO
Ha nestas paginas um servi o de \news" semanal que e muito util e que vo ê pode re eber
atraves de uma lista, se quiser. Para usar o programa apt-get para um upgrade, vo ê
pre isa roda-lo duas vezes. Da primeira vez vo ê vai rodar o programa na forma
apt-get update
que vai puxar dos servidores que estiverem ongurados no arquivo de ongura ~ao
/et /apt/sour es.list as bases de dados sobre o que esta disponvel e em que vers~oes.
Na segunda vez vo ê usa o programa na forma
apt-get -fu upgrade
que ira realizar os upgrades ne essarios, omparando a situa ~ao de sua maquina om
as novas bases de dados que foram puxadas. Em prin pio e possvel que sejam feitas
pelo instalador algumas perguntas sobre a ongura ~ao dos novos pa otes, mas isto
raramente a onte e em meros upgrades de pa otes. De qualquer forma, n~ao e uma boa
ideia fazer este tipo de oisa atraves de jobs do programa ron.
No aso dos nos, em espe ial se forem em grande numero, vai ser ne essario automatizar esta opera ~ao. A ideia e ome ar fazendo o upgrade do no virtual n0000,
aproveitando para veri ar se e ou n~ao feita alguma pergunta. Caso n~ao seja, o que e
provavel, basta es rever um s ript de shell para rodar os omandos em todos os nos,
usando o omando rsh, rodando o s ript no servidor ou no front-end. Caso seja feita
alguma pergunta, deve-se olo ar a resposta (em geral um ou mais dgitos ou palavras)
em um arquivo e in luir no s ripts um redire ionamento de input para este arquivo, de
forma a automatizar ompletamente as opera ~oes sobre os nos.
Outra alternativa e rodar um s ript que apenas fa a a abertura dos pa otes, sem
a sua ongura ~ao, deixando a ongura ~ao para ser feita a m~ao, se isto hegar a ser
ne essario. Em qualquer aso, ao terminar o upgrade de todos os nos n~ao se esque a de
rodar os s ripts hard-link- ommon-files-root e hard-link- ommon-files-var nos
lesystem do servidor de dis os, tanto no que ontem os diretorios / quanto nos que
ontem os diretorios /var dos nos.
4.3.3 Comentarios sobre ada Componente

Ha alguns omentarios a fazer sobre os upgrades de software de ada um dos omponentes do PMC.
Upgrades do Front-End: O kernel e a distribui ~ao Debian do front-end devem ser
mantidos t~ao atualizados quanto possvel. A atualiza ~ao da distribui ~ao e parti ularmente importante devido ao fato de que esta maquina esta na Internet, de
forma que devemos ser mais uidadosos om os problemas relativos a seguran a.
4.3. UPGRADES DE SISTEMA
51
Upgrades do Servidor: As ne essidades de atualiza ~ao do servidor s~ao menores do
que as do front-end. Entretanto, e importante manter o kernel atualizado. Ja as

preo upa ~oes de seguran a s~ao bem menores neste aso, pois a maquina esta numa
rede privada, so quem tem a esso ao front-end pode ter a esso a ela, de forma que
as preo upa ~oes de seguran a podem se limitar ao front-end.
Upgrades do Terminal: As ne essidades de atualiza ~ao do terminal tambem s~ao menores do que as do front-end. Entretanto, e sempre uma boa ideia manter o kernel
atualizado. As preo upa ~oes de seguran a tambem s~ao menores neste aso.
Upgrades dos Nos: As ne essidades de atualiza ~ao dos nos s~ao muito pequenas. Aqui
tambem n~ao pre isamos ter grandes preo upa ~oes om a seguran a. Como se trata
de maquinas om uma fun ~ao muito espe a, uma vez que elas estejam desempenhando suas fun ~oes a ontento, raramente deve ser ne essario fazer upgrades
da distribui ~ao, o que e onveniente pois estes upgrades podem ser bastante laboriosos se o numero de nos for grande. Por outro lado, mais uma vez e uma
boa ideia manter o kernel atualizado, o que e, afortunadamente, uma opera ~ao
relativamente simples e automatizavel para o onjunto dos nos.
Como se vê. pode-se lidar fa ilmente om a quest~ao dos upgrades de software, sem
muito trabalho e de forma bem simples.
Captulo 5
Comentarios
5.1 Algumas Pondera o~es e Justi ativas
5.1.1 Pe as e n~ao Maquinas Prontas
A estrategia de pro edimento que propomos para a montagem dos sistemas e a aquisi ~ao
das pe as om subsequente montagem das maquinas, em vez da aquisi ~ao de maquinas
prontas. Ha varios motivos para isto. Antes de mais nada, a aquisi ~ao de maquinas
montadas de mar as onhe idas, uni a forma de garantir a qualidade tanto das pe as
quanto do trabalho de montagem, aumenta onsideravelmente os pre os, podendo hegar
a inviabilizar nan eiramente o seu projeto.
Alem disso, em geral as ompanhias grandes têm uma onsideravel rigidez de ongura ~ao e frequentemente n~ao e possvel obter exatamente o que se quer em termos
das pe as que omp~oem o onjunto. Isto pode ser um problema devido, em parti ular,
a ne essidade de que haja suporte no Linux para as pe as que vo ê vai adquirir, um
fator que e frequentemente ignorado pelos fabri antes de maquinas prontas. A aquisi ~ao
separada das pe as para as maquinas permite que vo ê ontrole o tipo e qualidade de
todas elas e que vo ê determine exatamente as ara tersti as do seu hardware. Quanto
a montagem, vo ê ertamente a fara om mais uidado e menos problemas que aqueles
que tipi amente s~ao en ontrados em montagens destas pequenas rmas de \fundo de
quintal".
Entretanto, um dos motivos mais fortes para a ado ~ao desta estrategia e a ne essidade
de se realizar li ita ~oes para as aquisi ~oes em organismos de direito publi o omo e o
aso da maior parte das universidades serias deste pas. A ne essidade de realizar todas
as aquisi ~oes atraves de li ita ~oes e uma das piores pragas om que temos de onviver
nestas universidades. A existên ia de um pro esso li itatorio em si n~ao e o pior problema,
anal vo ê ertamente iria pesquisar o mer ado e omparar pre os de qualquer forma
antes de realizar suas ompras. O problema e que estas li ita ~oes o orrem atraves de
normas e rituais rgidos, omplexos e buro rati os, tanto os ditados pela lei quanto
aqueles ditados pelas regulamenta ~oes administrativas das proprias institui ~oes.
52
~
5.1. ALGUMAS PONDERAC
OES
E JUSTIFICATIVAS
53
E extremamente dif il e arris ado adquirir orretamente aquilo de que vo ê pre isa
nestas ondi ~oes. Se vo ê zer li ita ~oes para maquinas ompletas e algo der errado no
pro esso li itatorio, tal omo ganhar um equipamento de pessima qualidade, o que e
um problema omum e frequente, a uni a alternativa que pode restar e an elar a oisa
toda om total perda do tempo e do esfor o investidos no pro esso de aquisi ~ao. Por
outro lado, se a li ita ~ao for feita pe a-a-pe a, om uidadosas e minu iosas des ri ~oes
te ni as de ada pe a, na pior das hipoteses alguns tens ter~ao de ser refeitos. Uma
dis rimina ~ao su iente de uma maquina ompleta seria t~ao longa e omplexa que e
possvel que nenhum forne edor se apresentasse para ompetir. Alias, as li ita ~oes s~ao
de fato atividades muito laboriosas e dispendiosas para as empresas e e frequentemente
dif il onseguir que muitas delas sequer parti ipem de uma li ita ~ao.
Para nalizar, a arquitetura de montagem que propomos para os nos e su ientemente radi ar para que se possa garantir que nenhuma empresa poderia forne er o onjunto
de nos prontos. Pois bem, quem vai montar 10, 20 ou 30 nos pode muito bem montar
mais três maquinas para servirem de front-end, de servidor e de terminal. Depois de
passar por um projeto omo este vo ê provavelmente des obrira que as maquinas que
vo ê mesmo monta s~ao, em geral, de qualidade muito boa e talvez a mesma estrategia
deva ser usada para os servidores e terminais de uso geral da sua rede!
5.1.2 Arquitetura Intel e n~ao Alpha
A arquitetura que propomos usa ex lusivamente mi ro-pro essadores om a arquitetura

da famlia Intel, n~ao da Alpha ou de outras famlias de mi ro-pro essadores. Ha varios
motivos para isto. Uma das mais importantes e que as ultimas gera ~oes de hips da
famlia Intel e seus lones apresenta desempenhos muito superiores aos nvel que s~ao os
tradi ionais para esta famlia. Vo ê pode obter informa ~ao objetiva sobre o desempenho
de hips e maquinas para al ulo numeri o ataves da referên ia [13. Apesar de que n~ao
se trata ainda dos pro essadores mais rapidos do mer ado, se ompararmos hips om a
mesma frequên ia de lo k das diversas famlias, eles têm desempenhos omparaveis om
os das outras famlias e pre os mais baixos, de forma que sua rela ~ao usto/desempenho
e mais favoravel. Esta e uma das vantagens de estarmos pro essando em modo paralelo,
n~ao dependemos da velo idade de um uni o pro essador isolado e sim de um onjunto
deles. Se um erto pro essador e um pou o mais lento mas muito mais barato, podemos
adquirir um numero maior deles e a abar om um desempenho total superior.
Entretanto, ha varios motivos relativos ao software que tambem nos levam a preferir
esta arquitetura, tornando sua es olha essen ialmente inevitavel. A arquitetura Intel
e a uni a para a qual o onjunto ompleto dos softwares ne essarios para fazer operar
o PMC na forma omo des revemos aqui esta disponvel om fun ionamento estavel.
Por exemplo, se es olhêssemos a arquitetura Alpha n~ao seria possvel fazer o boot pela
rede, uma ara tersti a importante, que torna muito mais simples e robusta a opera ~ao
dos equipamentos. Alem disso, ate re entemente n~ao havia ompiladores disponveis
por pre os baixos que rodassem no Linux e fossem e ientes para a arquitetura Alpha,
54

CAPITULO 5. COMENTARIOS
o ompilador e iente que existia era proprietario. So re entemente uma vers~ao deste
ompilador foi portada para o Linux e disponibilizada sem pagamento atraves da rede,
para entidades de ensino e pesquisa; entretanto, note-se que ainda n~ao se trata de free
software. Por outro lado, os ompiladores do projeto GNU s~ao open sour e, gratuitos
e apresentam ex elente e iên ia na arquitetura Intel. Dados os ns a que um sistema
PMC de destina, a importân ia da disponibilidade de bons ompiladores e obvia, de
forma que este fato por si so ja e determinante para a es olha da arquitetura.
Outro ponto muito importante e a qualidade de opera ~ao e a estabilidade de todo
o software de sistema. Apesar de que o Linux e todos os demais softwares asso iados ja fun ionam bem em outras arquiteturas, ontinua sendo verdade que ele ainda e
bem mais estavel e livre de problemas na arquitetura Intel. Varias vezes bugs em novas
vers~oes deste ou daquele software, que apare em omo pequenos problemas opera ionais
na arquitetura Intel, traduzem-se em serias di uldades de opera ~ao em outras arquiteturas. Por exemplo, neste momento o Linux esta passando por uma rise relativamente
prolongada relativamente aos sistemas de NFS, que s~ao essen iais para o nosso projeto.
Isto esta rela ionado om uma mudan a grande que esta sendo feita neste momento na
area de servidores de NFS, pois estamos passando do velho servidor que fun iona no
\user-spa e" para um novo que esta integrado ao kernel. A instala ~ao do novo servidor
em nosso prototipo de arquitetura Intel se pro essou sem muitas di uldades e ele ja
esta fun ionando de forma estavel. O mesmo upgrade feito em nosso luster mais antigo, que e onstitudo de Alphas, ausou problemas su ientemente serios para sermos
for ados a retornar temporariamente ao sistema anterior.
Outro motivo muito forte e a fa il disponibilidade dos pro essadores e das motherboards da arquitetura Intel no mer ado na ional. Para o uso de outras arquiteturas seria
ne essario pro eder a pro essos de importa ~ao. Estes pro essos de importa ~ao oneram
muito os produtos que s~ao importados, tirando-os da ompeti ~ao no que diz respeito a
rela ~ao usto/desempenho. E verdade que muitas vezes as universidades podem importar equipamentos que se destinem a pesquisa atraves da lei 8010, om isen ~ao de taxas
de importa ~ao mas, se pro esso de importa ~ao de forma geral ja s~ao lentos e trabalhosos, pro essos de importa ~ao atraves da lei 8010 s~ao extremamente lentos, trabalhosos,
buro rati os e dif eis, podendo hegar a inviabilizar o projeto. Assim, a disponibilidade
das pe as no mer ado na ional e essen ial para tornar este tipo de projeto viavel e exe utavel por pequenos grupos de pesquisadores em lugares relativamente isolados. Assim,
mais uma vez vemos que as onsidera ~oes prati as nos levam a es olher a arquitetura
Intel e seu lones omo uni a possibilidade real para o projeto.
Para a onstru ~ao de nosso prototipo es olhemos o pro essador Athlon da AMD
(K7), om frequên ia de 800 MHz. Trata-se de um lone da arquitetura Intel, que tem
apresentado ex elente rela ~ao de pre o/desempenho. Depois de toda uma historia de
problemas om o desempenho em opera ~oes de ponto utuante, que se estende ate o
ante essor do Athlon, o hip K6, om o lan amento deste pro essador a AMD quebrou
em grande estilo o monopolio da Intel para pro essadores de bom desempenho nesta
~
5.2. PREOCUPAC
OES
COM A INFRA-ESTRUTURA
55
famlia. Este pro essador tem apresentado ex elente desempenho nos testes que temos
feito, hegando bem proximo de 250 M ops para datasets de tamanhos realsti os ( orrespondentes a redes de 10000 stios em 4 dimens~oes) em termos dos problemas om
que lidamos em nosso grupo de pesquisa. A es olha da frequên ia de 800 MHz, mesmo
ja existindo hips om frequên ias maiores, foi motivada pela optimiza ~ao da rela ~ao
pre o/desempenho. Alem de bem mais aros, os hips om frequên ias mais altas s~ao
relativamente mais dif eis de se obter no mer ado na ional.
5.2 Preo upa o~es om a Infra-Estrutura

5.2.1 Metodo de Alimenta ~ao de For a
A arquitetura proposta prevê o uso de dois tipos diferentes de no-break, um tipo bem
simples e barato para uso nos nos e outro bem mais sosti ado e aro para uso no
servidor. Como os nos n~ao têm dis os, s~ao relativamente menos sus eptveis a rudos da
alimenta ~ao de for a. Alem disso, omo eles montam todos os seus arquivos remotamente
atraves de NFS, sua queda brus a devido a uma falta de for a n~ao pode dani ar os
lesystems. E laro que dados podem ser perdidos numa tal situa ~ao, mas apenas
aqueles que estiverem sendo manipulados no momento da queda. Os objetivos de se
olo ar no-breaks nos nos s~ao dois: dar a eles um nvel basi o de prote ~ao eletri a e
permitir que os seus sistemas opera ionais sobrevivam a quedas urtas e pis adas na
alimenta ~ao de for a, mantendo aberta uma janela de tempo maior para a realiza ~ao de
al ulos longos.
Ja no aso do front-end, do servidor e do terminal a situa ~ao e diferente. O servidor
tem dis os deli ados, de alto desempenho, por isto ne essita da melhor prote ~ao possvel.
Neste aso estamos re omendando um no-break de alta qualidade do tipo \on-line".
Apesar de bem mais aros, estes no-breaks forne em um nvel de prote ~ao essen ialmente
perfeito. Alem disso, neste aso o servidor deve ter omuni a ~ao om e ontrole sobre o
no-break: por um lado o no-break deve enviar ao servidor sinais de aviso de que a for a
aiu e, depois disto, de que as baterias est~ao baixando; por outro lado, o servidor deve
ser apaz de desligar o no-break depois de ompletar os pro edimentos de shutdown
automati o dos sistemas. O servidor fara, alem do seu proprio, o shutdown do frontend, do terminal e de todos os nos, atraves da rede privada. Na realidade, o ontrole do
no-break pode estar tanto no servidor quanto no front-end.
Observe-se que a arquitetura prevê uma fonte separada para ada um dos nos. Como so se onsegue a har estas fontes ATX no mer ado na ional por bons pre os om
potên ias na faixa de 300 W, isto representa uma onsideravel sub-utiliza ~ao das fontes,
pois ada no n~ao dissipara mais do que er a de 100 W. Nossas medidas em um Athlon
K7 de 800 MHz om 256 MB de RAM, em plena opera ~ao, indi aram uma dissipa ~ao
maxima de er a de 95 W. Esta es olha foi feita para simpli idade na montagem e na
opera ~ao do sistema, em espe ial porquê este tipo de fonte e ontrolado pela mother-
56

board e poderia haver interferên ias indesejadas aso mais de uma motherboard fosse
ligada a uma mesma fonte. O problema de se obter e ligar varios one tores a uma
uni a fonte tambem e indesejavel.
Em termos de pre o o impa to desta de is~ao n~ao e grande, pois a fonte e uma das
pe as mais baratas do onjunto, sendo vendida a er a de R$ 50.00 ou R$ 60.00 ada
uma. Uma das preo upa ~oes que tivemos foi de veri ar se as fontes n~ao teriam um onsumo \basal" ( onsumo interno, quando n~ao ha arga na sada da fonte) muito grande,
o que poderia aumentar o onsumo total, tendo um impa to negativo nas ne essidades
de no-breaks e de alimenta ~ao eletri a do onjunto de uma forma geral. As medidas que
zemos mostram que isto n~ao e de fato uma preo upa ~ao relevante. O onsumo basal
que medimos em algumas fontes variou de 0.1 A a 0.2 A sob 120 V, o que orresponde a
uma potên ia de 12 W a 24 W. Fontes mais modernas e de melhor qualidade tentem a
ter um onsumo basal menor, mas de qualquer forma os numeros n~ao hegam a ausar
preo upa ~ao.
5.2.2 Temperatura e Refrigera ~ao
Em espe ial se vamos onstruir uma maquina om muitos nos, e importante que nos
preo upemos om o fato de que o onjunto dos equipamentos ira dissipar uma quantidade
onsideravel de alor, o que podera aumentar bastante a temperatura da sala onde
estar~ao operando. A solu ~ao usual para este tipo de problema e a instala ~ao na sala
de equipamentos de ondi ionamento de ar, o que pode ser um dispêndio adi ional
onsideravel no aso de maquinas om muitos nos. Mas, na realidade, as ne essidades de
refrigera ~ao dos nos e dos servidores s~ao bem diferentes, o que nos permite a alternativa
de adotar solu ~oes diferen iadas em ada aso.
Os omponentes mais deli ados de todo o onjunto s~ao os dis os SCSI que est~ao
no servidor de dis os. Para que tenham uma longa vida util destituda de problemas,
estes dis os pre isam de um ambiente opera ional muito estavel, em parti ular om
temperaturas baixas e bem onstantes. Ja no aso dos nos, que n~ao tem qualquer
tipo de dis o ou mdia magneti a, pre isamos apenas nos erti ar que o alor que e
produzido e retirado om su iente rapidez, de forma que ele n~ao se a umule e a abe
elevando a temperatura para nveis t~ao altos que provoque o mau fun ionamento dos
pro essadores. O ponto e que os nos s~ao muito menos exigentes do que o servidor de
dis os no que diz respeito ao ontrole de temperatura. Ja tivemos por aqui um CPU uja
ventoinha estava ompletamente entupida por po a umulado e que estava fun ionando
t~ao quente que n~ao se podia to ar no dissipador sob ris o de queimadura. Entretanto,
ele ainda fun ionava de forma orreta, sem nenhum erro.
Algumas vezes o aumento ex essivo da temperatura pode ome ar a ausar erros
de pro essamento do CPU, que passa a se omportar errati amente, em geral omo
onsequên ia de uma ma montagem do dissipador no orpo do CPU, por exemplo por
falta de pasta termi a na regi~ao de ontato entre os dois. Mas, desde que tenham seus
dissipadores e ventoinhas orretamente instalados, os CPUs modernos podem fun ionar
~
5.2. PREOCUPAC
OES
COM A INFRA-ESTRUTURA
57
sem problemas em ambientes sem ondi ionamento de ar, em quaisquer temperaturas

que sejam toleraveis para uma pessoa saudavel. Ha pouqussimo ris o de danos ao CPU
devido a aumentos da temperatura ambiente. Alem disso, as motherboards modernas
em geral têm dispositivos de monitoramento da temperatura do CPU, bem omo da sua
ventoinha de refrigera ~ao, de forma que podemos programa-las para se auto-desligarem
de forma automati a aso a temperatura passe de um determinado limite, de forma que
n~ao ha motivo de preo upa ~ao om a seguran a opera ional dos CPUs.
Desta forma, se estivermos onstruindo uma maquina relativamente grande e n~ao
quisermos gastar demais om a infra-estrutura, podemos optar por uma separa ~ao dos
nos e dos demais servidores, que podem ser instalados em salas diferentes. O servidor
de dis o deve ser olo ado em uma sala om bom ondi ionamento de ar e os nos em
outra sala, sem ondi ionamento de ar mas om um bom sistema de ventila ~ao para
o exterior, que garanta a retirada onstante e e iente do alor produzido dentro da
sala. Os equipamentos de rede devem ar junto om os nos, pois tambem n~ao têm
qualquer tipo de mdia magneti a e s~ao portanto mais tolerantes ao alor e a varia ~oes
de temperatura, alem do que havera um grande numero de abos de rede one tando
os nos a eles. O terminal e o front-end, que tambem têm dis os, devem ar na sala
do servidor, sob ar ondi ionado, para a qual devem ser passados os três abos de rede
ne essarios para a liga ~ao destes equipamentos.
O dimensionamento dos equipamentos de ondi ionamento de ar para a sala pode
ser feito fa ilmente, desde que existam nela boas ondi ~oes de isolamento termi o. Se as
uni as fontes de alor dentro da sala forem equipamentos eletri os, a regra de al ulo e
a seguinte: al ule, em Watts, a potên ia eletri a total que e dissipada onstantemente
omo alor dentro da sala. Multiplique o resultado por 3.416 para obter o numero de
BTU/h que e ne essario instalar na sala:
Numero ne essarios de BTU/h = 3.416 Numero de Watts.
A unidade BTU/h e frequentemente abreviada para BTU quando se fala sobre aparelhos
de ondi ionamento de ar, que existem om apa idades variadas, no formato padr~ao
que se instala numa parede em uma bandeja de on reto, deste er a de 5000 BTU ate
30000 BTU. Alguns pre os aproximados para alguns equipamentos tpi os s~ao dados no
apêndi e B.
No aso dos omputadores prati amente toda a potên ia eletri a que eles onsomem a aba sendo onvertida em alor dentro da sala, de forma que e simples al ular
a quantidade de alor produzido. O maior problema e avaliar orretamente as ne essidades em uma sala onde existam outras fontes de alor dentro da sala, ou uma isola ~ao
termi a insu iente om o exterior. Um exemplo de outra fonte de alor interna e o
sistema de ilumina ~ao, aso ele que sempre ligado. Caso haja pessoas dentro da sala
onstantemente, vo ê deve ontar er a de 300 W adi ionais para ada uma. Exemplos
tpi os de outras fontes de alor s~ao: janelas, mesmo se fe hadas om vidro; portas
que s~ao onstantemente abertas e fe hadas, levando a tro a de ar om o exterior: um
58

teto sem isola ~ao termi a, onde bata sol forte o dia todo. No aso de janelas, podem
estar entrando de uma a varias entenas de Watts por metro quadrado, dependendo das
ir unstân ias. Outros asos s~ao mais dif eis de se avaliar.
A re omenda ~ao para enfrentar estes problemas e reformar a sala para: fe har todas
as janelas om tijolos; providen iar isolamento termi o do teto; manter a porta tran ada, om as luzes apagadas e organizando as oisas de tal forma que ninguem frequente
demais a sala. Os equipamento estar~ao perfeitamente felizes fun ionando sozinhos no
es uro. Todo o a esso pelos usuarios e a maior parte das opera ~oes de administra ~ao
podem ser ser feitos remotamente, de forma que apenas raramente havera ne essidade
de ompare imento de uma pessoa a sala. Em boas ondi ~oes, as ne essidades de ondi ionamento de ar de nosso exemplo de 6 nos s~ao bem a eitaveis, mesmo se olo armos
todos os equipamentos em uma uni a sala: ne essitaremos de er a de 3000 BTU para
os 6 nos e de 2000 BTU para os servidores, perfazendo um total de 5000 BTU, que pode
ser forne ido onfortavelmente por um equipamento pequeno, de 7500 BTU, obtenvel
por er a de R$ 700.00. Havendo possibilidade e onveniente prever a instala ~ao de dois
equipamentos, o que nos da um fator de seguran a no aso da quebra ou ne essidade de
retirada para manuten ~ao de um deles.
5.3 Perspe tivas de Desenvolvimento Futuro

5.3.1 Possibilidades de Expans~ao do Cluster
A arquitetura de luster que apresentamos aqui e expansvel de forma relativamente
fa il ate grandes numeros de nos de pro essamento. Ate um erto ponto, a expans~ao se
da de forma linear em termos do investimento, ou seja, o pre o total do PMC sobe de
forma aproximadamente linear om o poder de al ulo instalado. Isto e verdade, e laro,
a menos de varia ~oes nos valores dos investimentos devidos a granularidade mnima om
que se pode realiza-los. Por exemplo, podemos adquirir um no novo de ada vez, mas
n~ao podemos adquirir uma porta nova de um swit h de rede, e ne essario adquirir um
swit h de 24 portas de uma vez so. Este tipo de irregularidade n~ao modi a, na media de
um grande numero de nos, a linearidade da rela ~ao entre o investimento e o desempenho
do PMC.
Ha entretanto alguns patamares no numero de nos uja ultrapassagem envolve um
investimento pontual adi ional de porte signi ativo. Um exemplo disto e o proprio
in io da onstru ~ao do luster, pois e ne essario pagar de uma vez pelo front-end, pelo
servidor e pelo terminal, dispêndios estes que n~ao se repetir~ao depois. Entretanto, em
geral estes patamares est~ao rela ionados aos detalhes dos equipamentos de rede que est~ao
disponveis neste momento. Dis utimos abaixo estes patamares para os equipamentos
disponveis atualmente no mer ado. Note-se que estes omentarios s~ao validos para a
te nologia de rede disponvel neste momento, desenvolvimentos desta te nologia podem
ter forte impa to no sentido de abaixar pre os e aumentar o desempenho dos sistemas,
5.3. PERSPECTIVAS DE DESENVOLVIMENTO FUTURO
59
omo veremos na se ~ao 5.3.2.

Ate 45 nos: E possvel ir ate este numero de nos sem investimentos adi ionais na infraestrutura da rede privada. Isto se deve ao fato que e possvel interligar diretamente
dois swit hes 3300 XM da 3COM atraves de um abo \matrix" que usta apenas
R$ 300.00. Com isto teremos efetivamente um swit h de 48 portas e, des ontandose as três portas ne essarias para o front-end, o servidor e o terminal, podemos
interligar atraves deles ate 45 nos.
Ate 93 nos: Com um investimento adi ional bem moderado podemos ir ate 93 nos,
atraves da liga ~ao de ate quatro swit hes 3300 XM da 3COM atraves de abos
matrix, o que exige a aquisi ~ao de um modulo adi ional que e uma espe ie de
\matrix-hub", om um usto da ordem de R$ 2000.00. Tambem e possvel fazer a
mesma oisa adquirindo-se para o ter eiro swit h o modelo 3300 MM, que ja vem
om um destes matrix-hubs internamente. Com isto teremos efetivamente um
swit h de 96 portas e, des ontando-se as três portas ne essarias para o front-end,
o servidor e o terminal, podemos interligar atraves deles ate 93 nos.
Ate 188{189 nos: Com um outro investimento ainda relativamente moderado, podemos ir ate er a de 190 nos. Para fazer isto e ne essario adquirir dois dos novos
4 swit hes ne essarios de um modelo um pou o mais aro. Trata-se do modelo
3300 TM, o qual possui, alem da possibilidade de liga ~ao por abo matrix, uma
porta TP de 1 Gbps. Atraves de simples abo TP ruzado podemos interligar
desta forma dois sta ks de 4 swit hes ada um, levando o numero total de portas disponveis para 192. Alem disso seriam ne essarios mais dois swit hes, um
3300 MM e um 3300 XM, e laro. O investimento adi ional em rela ~ao ao nvel
anterior neste aso sera da ordem de R$ 2000.00 de pre o adi ional para ada um
dos dois swit hes TM, perfazendo um total de er a de R$ 4000.00 adi ionais.
Observe, entretanto que o onjunto todo n~ao e mais equivalente a um uni o swit h
de 192 portas, trata-se de dois swit hes interligados por uma liga ~ao rapida, mas
que e na realidade um anal que podera estar ompartilhado por mais de uma
liga ~ao, entre nos que estejam ligados em um dos dois swit hes om nos que estejam
ligados ao outro swit h. Neste aso pode ser que se des ubra ser onveniente
olo ar dois servidores de dis o independentes, um para ada swit h. Dependendo
de termos, desta forma, quatro maquinas adi ionais (um front-end, um terminal
e dois servidores de dis os) em vez de três, poderemos ter entre 188 e 189 nos ao
todo.
Alem de 190 nos: Para ir alem deste numero de nos e ne essario interligar varios
sta ks, om quatro swit hes ada um, atraves do uso de um swit h de 1 Gbps.
Existe um swit h de 12 portas TP da 3COM, o modelo 4900, part number 3C17700,
que pode ser usado para isto. Ha neste aso um investimento adi ional substan ial,
pois este swit h esta sendo vendido por er a de R$ 14200.00. Entretanto, este
60

pre o ainda e bem menor do que o investimento orrespondente para o aso de

portas de bra oti a, pois o mesmo swit h 4900 om portas oti as (part number
3C93012) esta sendo vendido por er a de R$ 30000.00.
Por outro lado, pode-se ertamente hegar ate pou o mais de 1100 nos, om apa idade de pro essamento real de mais de 250 G ops om os CPUs usados em nosso
exemplo, mas que poderia hegar perto de um Tera op om os pro essadores mais
rapidos que est~ao sendo lan ados ou que ser~ao lan ados em breve. Para este tipo
de sistema om erteza sera ne essario ter varios servidores de dis o, possivelmente
um por sta k de swit hes, perfazendo talvez uma dezena deles.
E muito provavel que, muito antes que alguem tenha de fato os meios (algo na faixa
de R$ 2 milh~oes) para montar algo deste tamanho, a te nologia tenha mudado ompletamente, tornando quaisquer estimativas mais pre isas de pre o e desempenho
inuteis neste momento. De qualquer forma, os problemas de infra-estrutura (mais
de 100 KVA de alimenta ~ao eletri a, por exemplo) e geren iamento que estariam
envolvidos na onstru ~ao de uma maquina t~ao grande a olo am fora do es opo
deste do umento, que pretende auxiliar pequenos grupos a montar maquinas de
pequeno a medio porte.
Outra possibilidade em rela ~ao a rede e a liga ~ao do servidor de dis o diretamente
numa porta de 1 Gbps, o que pode ser feito para um uni o sta k de 96 portas ou para
um sistema maior, que in lua um swit h de 12 portas TP de 1 Gbps. Ja existe uma
pla a de rede PCI da 3COM, a de modelo 3C985B-SX, para a qual ha suporte no Linux.
Trata-se entretanto de uma pla a para onex~oes de bra oti a e, portanto, muito ara.
Seu pre o esta a por volta de R$ 2700.00. Alem disso, seu uso requeriria um swit h om
portas oti as, o que en are eria muito o onjunto. Por outro lado, e so uma quest~ao de
tempo ate estarem disponveis modelos desta pla a para abos TP, provavelmente por
menos da metade deste pre o.
Finalmente, ha a possibilidade de se olo ar mais de uma pla as de rede em ada no,
multiplexando-as na fun ~ao de uma uni a pla a e aumentando desta forma a velo idade
da onex~ao. Ao que pare e esta e uma das oisas feitas originalmente no projeto Beowulf.
Entretanto, om as pla as de 1 Gbps em bra ja se tornando disponveis e o lan amento
de pla as de 1 Gbps em TP ja apare endo no horizonte, n~ao pare e neste momento uma
ideia muito boa tentar fazer isto om pla as de 100 Mbps.
5.3.2 Possveis Desenvolvimentos Te nologi os
Fazemos aqui um explora ~ao dos desenvolvimentos te nologi os que est~ao a vista em
diversos prazos. Varios destes desenvolvimentos dever~ao ter impa to muito positivo
sobre o desempenho dos sistemas e sobre as raz~oes de pre o e desempenho.
Curto prazo: A vers~ao 2.4.0 do kernel a aba de ser lan ada; tanto quanto se saiba,
em termos de novas apa idades ela n~ao traz nada que possa ter impa to imediato
5.3. PERSPECTIVAS DE DESENVOLVIMENTO FUTURO
61
muito grande sobre este tipo de projeto em parti ular, ex eto por uma maior
solidez de fun ionamento, por exemplo espera-se que o sistema NFS e o sistema de
montagem automati a autofs passem a fun ionar melhor; entretanto, e onveniente
esperar que ela se estabilize bem antes de tentar um upgrade, possivelmente a
partir da vers~ao 2.4.10, mais ou menos.
Espera-se para breve o lan amento do pro essador \Itanium" (ex-\Mer ed"), o
novo pro essador de 64 bits da Intel. Quando for lan ado este pro essador provavelmente sera o mais rapido em existên ia, devido ao fato de que ele foi desenvolvido pela Intel em olabora ~ao om a Hewlett-Pa kard (HP), uja maquina de
pro essamento de oating-point, que esta sendo usada neste novo hip e que e
usada na arquitetura PA-Ris de sua linha atual de pro essadores, e uma das mais
e ientes em existên ia, ou seja, que onsegue realizar o maior numero de opera ~oes de ponto utuante por i lo de lo k. Testes preliminares que est~ao sendo
publi ados neste momento indi am que este pro essador devera forne er mais de
1.1 G op para uma frequên ia de lo k de 1 GHz.
O pro essador e ompatvel om o instru tion-set tradi ional da Intel e seu desenvolvimento esta a onte endo de forma bem aberta, sendo in lusive que ja ha um
porte do Linux em andamento para este pro essador e ele de fato ja rodou nele em
arater experimental, durante demonstra ~oes preliminares. Devido a isto, pode-se
prever que n~ao deve demorar muito depois do lan amento para termos disponveis
todos os elementos de software que nos permitir~ao utiliza-lo em um PMC. Isto deve
mudar por main uma ordem de magnitude a apa idade de al ulo dos PMCs.
Esta sempre aumentando o universo de hardware para o qual ha suporte do sistema
opera ional Linux. Apesar de que isto tem impa to maior sobre maquinas de uso
geral do que sobre o PMC, ha impa to sobre ele tambem. Por exemplo, novas
pla as de rede devem passar a ser suportadas para boot remoto atraves da rede.
Em breve deveremos ter redes Ethernet om velo idade de 1 Gbps trafegando
em abos TP ate o desktop, o que deve baratear imensamente a sua instala ~ao e
permitir o seu uso nas redes privadas dos PMCs.
Ha tipos novos e mais rapidas de memorias RAM (RDRAM em vez de SDRAM)
sendo desenvolvidos e lan ados atualmente, bem omo novas vers~oes, mais rapidas,
do bus PCI, fun ionando om larguras de 64 bits e frequên ias de 66 MHz, em vez
da atual largura de 32 bits e frequên ia de 33 MHz, alem de pro essadores om
bus lo al mais rapido e a hes se undarios mais rapidos e maiores. Ja existem
motherboards para o re em-lan ado Pentium 4 om memoria RDRAM fun ionando a 800 MHz, ou seja, de seis a oito vezes mais rapido do que o padr~ao atual
para a memoria SDRAM. Todos este s~ao fatores que poder~ao ter grande impa to
positivo sobre o desempenho e a disponibilidade de PMCs no futuro.
Medio prazo: Deve ser padronizado e se tornar a essvel no desktop o Ethernet de
1 Gbps trafegando em abos TP, o que nos dara mais uma ordem de magnitude de
62

aumento na velo idade da rede; alem da ontnua es alada na velo idade dos CPUs,
devem apare er memorias RAM mais rapidas e ada vez mais baratas, fatos estes
que devem tornar um no de 1 G op om 1 GB de RAM uma alternativa a essvel;
tambem deve se tornar de uso orriqueiro o bus PCI de 64 bits fun ionando a
66 MHz, a ompanhados de pla as de rede PCI orrespondentemente mais rapidas;
e possvel usar em nossa arquitetura nos multipro essados, om motherboards de
dois ou mais pro essadores, uma alternativa que por enquanto ainda e um tanto
ara, mas que pode se tornar atraente no futuro, pois motherboards de dois a
quatro pro essadores est~ao se tornando relativamente rotineiras.
No front do software deve ser estabilizado o proto olo NFS trafegando por TCP
em vez de UDP, o que aumenta muito a sua onabilidade; deve ser estabilizado
tambem o uso, ainda experimental hoje, de swap atraves da rede, envolvendo o uso
do NBD do Linux, apesar de que a utilidade desta alternativa em nossa arquitetura
e um tanto dis utvel; provavelmente os desenvolvimentos de maior impa to na
area de software ser~ao melhorias nos ompiladores, melhorias nas bibliote as de
passagem de mensagens PVM e MPI, o apare imento de drivers de nvel baixo
para pla as de rede, para permitir o seu uso mais direto para a passagem de
mensagens, sem passar pelo sta k de TCP/IP do kernel, possivelmente om o uso
de duas pla as de rede por no, bem omo mudan as algoritmi as na abordagem
dos problemas e a dissemina ~ao do uso de PVM e MPI.
Longo prazo: E muito dif il fazer uma ideia, mesmo que apenas aproximada, de o-
mo sera a informati a a longo prazo, mas de erto que ha a expe tativa de um
desenvolvimento ontnuo ainda por muitos anos; hips de CPU om dezenas de
GHz e dezenas de G ops, om liga ~oes de obre, om dissipa ~ao de energia muito menor que a de hoje, om a hes primarios bem maiores; memorias ada vez
mais rapidas e baratas, a ompanhadas de um bus lo al orrespondentemente mais
rapido; eventualmente deveremos ter hips multipro essados, ou seja, varios pro essadores ompletos em um uni o hip de material semi ondutor, ada um om
o seu a he, om um bus de velo idade extremamente alta interno ao hip, ou
mesmo om um swit h interligando os pro essadores.
Todos estes possveis desenvolvimentos teriam grandes impa tos positivos sobre o
desempenho de um PMC. Esperamos que a informati a ontinue se disseminando
e sendo produzida em massa, levando desta forma a redu ~ao de pre os, de forma
a olo ar todo este poder de al ulo ao al an e dos grupos de pesquisa e pesquisadores individuais. N~ao ha duvida de que o desenvolvimento da informati a ira
mudar de forma fundamental a forma de se fazer iên ia no futuro. Mas n~ao ha
omo prever os detalhes de omo isto vira a a onte er. Logo, quemos de olhos
bem abertos.
~ DOS RECURSOS
5.4. SOBRE A UTILIZAC
AO
63
5.4 Sobre a Utiliza ~ao dos Re ursos

5.4.1 Novo Paradigma de Programa ~ao
O uso e iente de um sistema de pro essamento paralelo omo o PMC requer um erto
esfor o de adapta ~ao dos pesquisadores em rela ~ao aos habitos tradi ionais de programa ~ao. A arquitetura de um sistema deste tipo esta baseado em novos paradigmas de
programa ~ao, que s~ao signi ativamente diferentes do paradigma tradi ional usado em
maquinas om um uni o pro essador mais poderoso, ou mesmo maquinas multipro essadas. De fato, pode-se mesmo dizer que toda a estrategia algoritmi a tradi ional e
mesmo a forma de se abordar alguns dos problemas pre isam ser revistas.
Naturalmente, a forma mais simples de se ome ar a utilizar um sistema paralelo e
usa-lo omo um sistema omputa ional multiplo, segundo a estrategia de \throughput
omputing". Isto tanto pode atender a demanda de um grupo grande de usuarios que
use individualmente e de forma independente nos do sistema, quanto um uni o usuario
que utilize a maquina da mesma forma, devido as ara tersti as do seu problema. Por
exemplo, ele pode ter de rodar um mesmo programa para um grande numero de ole ~oes
diferentes de ertos parâmetros. Apesar de haver um pre on eito entre os puristas sobre
esta ser uma forma \errada" ou inapropriada de usar este tipo de equipamento, isto n~ao
passa disto: um tolo pre on eito. O que importa e que as ne essidades omputa ionais
sejam satisfeitas da melhor forma possvel, este tipo de uso e perfeitamente orreto. De
fato, se o seu problema pode ser resolvido desta forma, n~ao tenha duvidas de fazê-lo,
pois trata-se de uma das formas mais e ientes de utilizar este tipo de re urso. N~ao
omplique o seu problema desne essariamente so porquê esta usando uma maquina que
permite pro essamento paralelo!
Este tipo de situa ~ao e ara terizado pelo fato de que estamos fazendo pro essamento simultâneo em onjuntos analogos mas diferentes de dados, sem que haja, em
nenhum momento, ne essidade de tro ar quaisquer tipos de informa ~oes entre as diversas instân ias do pro essamento. Tudo que pre isamos e oletar os diversos resultados
no nal do pro esso. Podemos dizer que n~ao ha ne essidade de sin ronizar os dados das
diversas instân ias de pro essamento. Muitos programas s~ao naturalmente deste tipo,
ou podem ser abordados algoritmi amente de tal forma que possam ser tratados desta
maneira. Programas que fazem oisas repetitivas de forma massi a, tais omo pro uras
sobre ou analise de grandes quantidades de dados, sempre podem ser tratados desta
forma. Um exemplo deste tipo de oisa e a renderiza ~ao de imagens atraves de \ray
tra ing". Existe um ex elente programa livre para este tipo de atividade, o Povray,
que ja vem om o suporte para PVM in ludo, o qual pode ser ativado atraves de uma
simples op ~ao do programa.
Outro exemplo simples de problema que pode ser tratado desta forma se usarmos a
abordagem apropriada e a maior parte dos problemas de simula ~ao esto asti a atraves
do uso de metodos de Monte Carlo, em espe ial nos asos da simula ~ao de distribui ~oes
de equilbrio termodinâmi o e do al ulo de integrais de dimens~ao alta. Em todos estes
64

asos temos algum tipo de pro esso esto asti o que esta produzindo amostragens de
algum observavel. O pro esso e estatsti o, quanto maior for o numero de amostragens
independentes que obtivermos, om mais pre is~ao poderemos medir os observaveis. Para
que as amostragens possam todas ontribuir independentemente para o resultado nal,
o que queremos e que sejam estatisti amente independentes umas das outras, ou seja, a
ultima oisa que queremos aqui e que existam dependên ias entre os diversos pro essos
e tro as de informa ~ao entre eles. Uma situa ~ao ideal, portanto.
Podemos simplesmente rodar uma opia do mesmo programa em ada no, nos preo upando apenas om o fato de que ada um dos pro essos esto asti os deve ser independente dos demais, o que pode ser feito om a manipula ~ao adequada das sementes
do gerados de numeros aleatorios. N~ao so devemos ini iar ada pro esso om uma semente que seja garantidamente diferente de todas as outras, omo podemos dar um
\tran o" no pro esso de vez em quando, mudando aleatoriamente a semente. O sistema
Linux tem um gerador forte (mas lento) de numeros aleatorios omo parte integrante do
kernel, o qual pode ser a essado pelo dispositivo /dev/random e fa ilmente usado para
esta nalidade. Vemos aqui omo uma mudan a simples na abordagem algoritmi a e de
programa ~ao pode nos permitir utilizar om grande e iên ia um sistema paralelo de
tamanho quase arbitrario, om um mnimo de trabalho de programa ~ao adi ional.
Entretanto, mesmo para problemas deste tipo pode ser vantajoso ir um pou o adiante
e aprender a usar as bibliote as de passagem de mensagens PVM e MPI. Por exemplo,
se vo ê estiver usando uma maquina de 1000 nos (n~ao usta nada sonhar um pou o), a
simples tarefa de entrar em ada um deles para submeter um job, ou mesmo o uso de
um s ript para fazer isto de forma mais automati a, ser~ao uma fatia muito grande do
seu trabalho de simples exe u ~ao do programa. Adi ionando a isto a ne essidade de se
veri ar que nos est~ao ou n~ao disponveis, ou om problemas, bem omo a ne essidade de
se monitorar o trans orrer do pro essamento, temos uma grande quantidade de trabalho
me âni o repetitivo. Atraves do uso das bibliote as PVM ou MPI, podemos es rever
um programa \master" que n~ao faz outra oisa alem de realizar todo este trabalho para
nos de uma forma bem automati a e muito onavel. Isto pode se tornar um diferen ial
importante na determina ~ao da sua qualidade de vida omo pesquisador.
A es rita de um programa de ontrole (master-program), que n~ao faz al ulos mas
que ontrola e oordena um grande numero de pro essos simultâneos que os realizam, e
apenas uma de muitas estrategias possveis de programa ~ao paralela. Ela tambem pode
ser usada em asos onde e ne essario fazer de tempos em tempos uma sin roniza ~ao de
dados entre todos os pro essos, om o uso de uma estrategia do tipo \s atter-gather",
na qual o programa master espalha tarefas de pro essamento pelos nos, re ebe de volta
resultados par iais, sin roniza os dados, volta a espalhar tarefas de pro essamento e
assim por diante, i li amente, ate que o problema tenha sido resolvido. Um exemplo
de situa ~ao onde se pode usar este tipo de estrategia e a resolu ~ao de problemas de eletrostati a ( ondi ~oes de ontorno para a equa ~ao de Lapla e) pelo metodo de relaxa ~ao.
N~ao vamos entrar aqui em maiores detalhes, mas apenas apontar o leitor para os links
~ DOS RECURSOS
5.4. SOBRE A UTILIZAC
AO
65
bibliogra os que podem ser en ontrados ao nal deste do umento.

Basta, para terminar esta se ~ao, observar que o riterio ru ial para que um esquema
de programa ~ao fun ione bem numa maquina omo o PVM e aquele que diz respeito a
quest~ao da granularidade da programa ~ao. Uma maquina omo o PMC e ara terizada
por ter nos de pro essamento muito fortes e uma rede om apa idade de omuni a ~ao
relativamente limitada. Outros esquemas, enfatizando enormes quantidades de nos de
pro essamento fra os, bem omo redes espe iais extremamente rapidas, ja foram tentados extensivamente no passado, levando a falên ia da maior parte das rmas que
tentaram produzir e omer ializar estes sistemas. Para que tenhamos sistemas paralelos
grandes e a essveis, e essen ial o uso de omponentes que sejam produzidos em massa
para outros ns, de onde de orrem as ara tersti as arquiteturais basi as do PMC.
Para que um sistema paralelo deste tipo fun ione om grande e iên ia e importante
que o \gr~ao" de pro essamento que e atribudo a ada no seja relativamente grande,
podendo o upar o no por algum tempo antes que seja ne essario passar mensagens e
tro ar dados om outros nos ou om o programa master. Se isto n~ao for o aso, os nos
estar~ao parados a espera de uma mensagem na maior parte do tempo e o desempenho do
sistema aira drasti amente. Assim, a losoa de programa ~ao apropriada para o uso do
PMC e re-examinar o seu problema a pro ura de forma de quebra-lo em gr~aos grandes,
que possam rodar bem em um no forte. Em seguida, e ne essario pensar nos metodos de
passagem de mensagens e sin roniza ~ao de dados que tenham a melhor han e de n~ao
deixar os nos esperando pela hegada da informa ~ao ne essaria para a ontinuidade do
pro essamento. Em problemas mais dif eis de se paralelizar fazer isto pode signi ar
uma mudan a ompleta dos algoritmos utilizados. Mas a redite, vai valer a pena!
5.4.2 Filosoa de Uso e Compartilhamento
A arquitetura do PMC foi on ebida de forma a fa ilitar ao maximo o ompartilhamento

dos re ursos entre grupos e usuarios. Quanto maior for a maquina, mais importante e
ter a possibilidade de se ompartilhar os re ursos, pois um pequeno grupo di ilmente
pode manter uma maquina grande o upada de forma ontnua, levando a uma situa ~ao
de grande o iosidade durante boa parte do tempo, o que representa um desperd io
de re ursos, que sempre s~ao es assos. Alem disso, a arquitetura foi planejada para
fa ilitar o uso remoto dos re ursos. N~ao so e possvel que usuarios remotos utilizem
um determinado sistema, omo tambem e possvel que varios sistemas espalhados pela
rede sejam utilizados de forma ooperativa no mesmo problema. Naturalmente, este
tipo de uso depende ru ialmente da qualidade da rede, em espe ial das liga ~oes de
longa distân ia. Desta forma, a arquitetura do PMC pode fazer uso de forma muito
onstrutiva das grandes melhorias que est~ao a onte endo nos ba kbones de rede do pas,
bem omo da Internet II, que ja esta em pro esso de instala ~ao, prometendo melhorias
ainda maiores no futuro.
Observe-se que, apesar de que o PMC n~ao se ongura omo sistema home de nenhum
de seus usuarios, a importa ~ao dos homes originais dos usuarios faz om que o uso
66

do sistema por eles seja o mais transparente possvel, mantendo todo o ambiente de
trabalho ao qual ele esta a ostumado em seu sistema de origem. Por isto, o PMC n~ao
in lui nenhum servi o de armazenamento de dados dos usuarios nem de entrada e sada
para meios magneti os, servi os estes que s~ao importados dos sistemas de uso geral de
origem de ada usuario. Assim, trata-se puramente de um servidor de poder de al ulo
que pode ser usado fa ilmente por qualquer um, om a esso apenas atraves da rede.
Devido a tudo isto o geren iamento do PMC e, de fato, muito simples, pois n~ao in lui
geren iamento de dis os om dados dos usuarios, atividades de ba kup ou tarefas de
ongura ~ao de ambiente de trabalho destes usuarios. Trata-se basi amente de manter
as maquinas em opera ~ao e, esporadi amente, abrir um ou outro pa ote de software, o
que da relativamente pou o trabalho.
Desta forma, ada grupo pode ter o seu proprio PMC, mantido sob sua propria
responsabilidade e ontrole, sem que isto impossibilite o ompartilhamento de re ursos
e leve a o iosidade. Por outro lado, e laro que tambem e possvel que varios grupos
ooperem na onstru ~ao de um uni o PMC. Por exemplo, no aso de um determinado
grupo ja ter ini iado a instala ~ao de um PMC, outros grupos ou mesmo pesquisadores
individuais podem ser a eitos omo \so ios minoritarios" mediante a ontribui ~ao ao
PMC de um determinado numero de nos. Ate ertos limites te ni os que est~ao expli ados
na se ~ao 5.3.1, novos nos podem ser adi ionados ao PMC a qualquer momento. Como
o pre o de um uni o no e relativamente baixo, ha grande exibilidade e e fa il para
indivduos ou pequenos grupos ontriburem para a amplia ~ao de um PMC.
Em muitos asos e perfeitamente possvel a um uni o usuario usar simultaneamente
varios PMCs espalhados pela rede, ate mesmo para rodar um uni o programa. E laro
que, aso os PMCs estejam mal one tados uns aos outros, isto so sera prati o para
programas que sejam muito pou o dependentes de boa one tividade entre os nos. Mesmo para programas mais exigentes em termos de one tividade, e sempre possvel usar
ada PMC para um job diferente e distribuir os jobs por varios PMCs, na losoa de
throughput omputing. Observe que, omo os nos de ada PMC est~ao numa rede privada, para rodar um mesmo programa numa ole ~ao de PMCs e ne essario ter programas
de ontrole rodando em ada front-end, para que eles possam tro ar dados uns om os
outros atraves da LAN, ou atraves da Internet se os PMCs estiverem distantes uns dos
outros em termos da rede.
As possibilidades de ompartilhamento s~ao muito limitadas e podem ate ser impossibilitadas se a institui ~ao n~ao tiver uma rede lo al aberta para a Internet. Infelizmente
muitas institui ~oes, mesmo institui ~oes publi as de ensino e pesquisa, tomam a pessima
de is~ao de fe har ompletamente as suas redes para a esso externo, em geral atraves
da infeliz instala ~ao de \rewalls" quase ompletamente fe hadas. Sob o ansativo e
ja batido pretexto do problema da seguran a, que pode perfeitamente ser resolvido de
formas bem menos destrutivas, estas institui ~oes est~ao, na realidade, se olo ando fora
do al an e de qualquer ajuda externa e, alem disso, impossibilitando a exporta ~ao de
quaisquer re ursos internos de sua rede, tomando assim uma atitude mope e egosta de
~

5.5. OUTRAS APLICAC
OES
DAS MESMAS IDEIAS
67
tudo usar mas nada ontribuir a Internet. Nestas ir unstân ias infelizes ainda e possvel
ompartilhar re ursos entre dois PMCs que estejam na rede lo al, mas a oopera ~ao om
grupos de outras institui ~oes am prejudi adas.
5.5 Outras Apli a o~es das Mesmas Ideias

As ideias e linhas mestras apresentadas aqui, tanto aquelas relativas ao hardware quanto
aquelas que dizem respeito ao software e ao fun ionamento onjunto dos dois, podem ser
uteis para outras apli a ~oes que n~ao um PMC. A des ri ~ao da instala ~ao e ongura ~ao
da rede se apli a a qualquer rede lo al que utilize o meio fsi o Ethernet, om qualquer
velo idade.
Nossa des ri ~ao do servidor de dis os apli a-se, om apenas pequenas modi a ~oes
e adi ~oes, a montagem e instala ~ao de um servidor entral de uso geral, departamental
ou de um grupo de pesquisa. A ongura ~ao de hardware seria a mesma, apenas om
o a res imo de mais um ou dois dis os para servirem de home e de ba kup das ontas
dos usuarios. Seria pre iso fazer adi ~oes mais signi ativas no onjunto de software a
ser instalado no servidor in luindo, por exemplo, um servi o de orreio eletrôni o e um
servidor de paginas de web. Um sistema de ba kup automati o das ontas de usuarios
tambem e uma boa ideia, o que pode ser feito de forma simples e onveniente om o uso
do omando tar.
De forma semelhante, nossa des ri ~ao do terminal se apli a, om algumas adi ~oes,
a montagem e instala ~ao de um terminal gra o X11 para uso individual por uma
pessoa, seja de forma privativa, seja em uma sala de terminais oletiva ou publi a. A
ongura ~ao do hardware seria a mesma, a menos do a res imo de uma pla a de som.
Ja na parte de hardware haveria uma serie de a res imos, n~ao so de todo o software
relativo ao som, omo de muitos apli ativos de uso geral. Para uma maquina deste tipo,
e importante dispor das unidades ZIP e CD de entrada e sada.
A nossa arquitetura de hardware e software para os nos tambem pode ser utilizada
de outras formas, para apli a ~oes bem mais radi ais e menos omuns. O sistema de boot
remoto e extremamente onveniente para a instala ~ao de termineis de uma forma geral.
Desta forma, eles n~ao pre isam ter dis os lo ais e podem ser bem mais tolerantes em
rela ~ao ao ambiente opera ional, independentemente de onde eles devam ser instalados
para onforto dos usuarios. Isto tambem diminui o nvel de rudo ausado pelo terminal.
Salas de terminais publi os podem ser instaladas sem nenhum dis o, usando um servidor
que que bem instalado e protegido em uma sala separada, onde n~ao haja trânsito de
usuarios.
De fato, uma sala de terminais publi a pode perfeitamente fun ionar tambem omo
um PMC, sem prejuzos para nenhuma das duas fun ~oes, pois os CPUs de uma sala de
terminais est~ao deso upados durante a maior parte do tempo, alem de que salas deste
tipo em geral n~ao am abertas mais do que umas 12 horas por dia. Basta instalar os
terminais om boot remoto, omo seria feito de qualquer forma, mas olo ar neles CPUs
68

mais fortes e mais memoria RAM do que seria olo ado normalmente em terminais. O
pre o total da sala sera maior, e laro do que o de uma sala de terminais omum om o
mesmo numero de terminais, bem omo do que o de um PMC puro om aquele numero
de nos. Ele sera, entretanto, bem menor do que a soma dos pre os das duas oisas, se
instaladas independentemente.
E laro que para que uma sala deste tipo possa fun ionar e essen ial que os terminais
operem ex lusivamente om o Linux, n~ao se pode ter maquinas om boot duplo. Para
evitar interferên ias indesejadas entre os dois tipos de fun ~ao, basta limitar a quantidade
de memoria que um pro esso possa utilizar, usando o sistema PAM do Linux, bem omo
rodar os jobs de pro essamento intensivo em las de baixa prioridade durante o dia,
instalando o sistema de las NQS. Com a estabiliza ~ao do sistema de swap atraves da
rede, este tipo de arquitetura devera ar ainda mais prati a e estavel. De qualquer
forma, esta te nologia permite que se instale todos os insumos basi os de informati a
om grande e onomia e fa ilidade, levando a sistemas muito estaveis, prati os, exveis,
om ex elente desempenho.
5.6 Variadas Alternativas Possveis

Existem muitas alternativas de modi a ~ao da arquitetura des rita neste do umento,
in lusive algumas simpli a ~oes que podem ser feitas para sistemas pequenos ou que
devam fun ionar sob ondi ~oes espe as. Por exemplo, e possvel unir as fun ~oes do
front-end e do servidor de dis os em uma uni a maquina, barateando um pou o o onjunto, o que pode ser importante para sistemas pequenos, onde o pre o dos servidores
pesa bem mais. Para que isto seja possvel vai ser ne essario usar o servidor de NFS antigo para todas as fun ~oes, o que e apenas um ompromisso bem limitado de desempenho
e estabilidade.
Alem disso, o front-end/servidor tambem pode ser integrado om o proprio servidor
de uso geral ja existente em um pequeno grupo de pesquisa, diminuindo muito, desta
forma, o investimento ne essario nos servidores. Em qualquer aso, re omenda-se que
o terminal nun a seja integrado om qualquer servidor, pois isto omprometeria muito
a estabilidade de opera ~ao do onjunto. Por outro lado, em um pequeno grupo pode-se
usar o terminal omo um dos nos de pro essamento, om apenas pequeno ompromisso
na estabilidade opera ional do sistema omo um todo. Com todas estas modi a ~oes
o investimento ne essario para olo ar em opera ~ao um pequeno PMC pode diminuir
onsideravelmente, viabilizando o projeto.
Caso ainda n~ao exista um espelho da distribui ~ao Debian na rede lo al de sua institui ~ao, vo ê tem a alternativa de instalar um tal espelho no front-end, o que pode ser
feito muito fa ilmente om o uso do programa wget. Neste aso havera a ne essidade
de um dis o dedi ado a esta fun ~ao, omo pelo menos uns 6 GB. Este espelho podera
servir tanto a rede privada do PMC quanto a LAN da sua institui ~ao, a seu riterio. Em
qualquer aso, a atribui ~ao ao front-end de servi os de dis o de qualquer tipo, seja para
5.6. VARIADAS ALTERNATIVAS POSSIVEIS
69
home de usuarios, seja para um espelho de software, deve ser a ompanhada da tro a
dos seus dis os IDE por dis os SCSI.
Outra alternativa para um grupo pequeno e oeso e utilizar os proprios terminais
de uso geral do grupo omo parte dos nos de um PMC. Neste aso vai ser ne essario
desistir ompletamente da rede privada e olo ar todos os nos, terminais e servidores
diretamente na rede lo al. Isto pode dar um pou o mais de trabalho de geren iamento,
mas isto n~ao e um problema muito serio para um sistema pequeno. Esta alternativa e
semelhante a ideia de se usar salas de terminais publi os tambem omo PMCs, que foi
exposta na se ~ao anterior.
Uma das alternativas interessantes para fa ilitar o uso dos onsoles seriais, em espe ial em sistemas grandes, onde alguns nos podem estar em posi ~oes n~ao fa ilmente
a essveis, e a instala ~ao de um omutador serial ligado ao terminal e as portas seriais de
ada no. Desta forma, para mudar o onsole de uma no para outro, basta usar o omutador, em vez de retirar e olo ar um uni o abo serial em um no quando e ne essario.
Outra alternativa para o diagnosti o e re upera ~ao de nos om problemas e o uso de
um sistema \super-res ue" ustomizado para o uso no PMC. O sistema super-res ue e
um Linux instalado num disquete ZIP de 100 MB, bootando dele ou de uma unidade
oppy omum de 1.4 MB. Com o uso de uma unidade ZIP externa, que se one ta ao
omputador atraves da porta paralela, este sistema poderia ser usado em um dos nos do
PMC. O sistema super-res ue usual pode ser obtido a partir dos servidores dos projetos
LinUSP e LinORG, que est~ao atualmente fora do ar mas que devem voltar a fun ionar
em breve. O endere o do servidor do projeto LinUSP e:
http://linusp.usp.br/
Este servidor abriga basi amente servi os de informa ~ao e omuni a ~ao, enquanto a
distribui ~ao de software esta on entrada nos servidores do projeto LinORG. O endere o
do servidor entral do projeto LinORG, que se lo aliza no ampus da USP na apital,
e:
http://linorg.usp.br/
Lembremos que o uso do sistema por usuarios remotos atraves de seus sistemas home
de origem requer uma a ordo sobre a distribui ~ao de numeros de usuarios (uid), de tal
forma que ada usuario tenha um uid uni o. Caso isto n~ao seja possvel por qualquer
motivo, ha a alternativa de se instalar um home no front-end para servir a alguns dos
usuarios. Neste aso os usuarios am en arregados de transferir a m~ao os seus dados do
front-end para os seus homes de origem e vi e-versa. Entretanto, omo esta alternativa
introduz no PMC o aspe to indesejado da ne essidade de administrar lo almente dados
de usuarios, uma alternativa melhor e a abertura pelos usuarios de novas ontas para
si em seus sistemas de origem, om numeros a eitaveis, que sejam usadas apenas para
a esso ao sistema PMC. Desta forma a transferên ia de dados dos usuarios de um lado
para o outro pode a onte er apenas dentro de seus sistemas de origem.
Apêndi e A
Problemas
A.1 Transi ~ao dos Servidores de NFS
Ha hoje dois servidores de NFS distintos disponveis para o sistema Linux. Um e o
servidor velho, que hamaremos de UNFSD e que roda no que se hama de \userspa e",
ou seja, em um pro esso omo qualquer outro programa de usuario. O outro e o novo
servidor que hamaremos de KNFSD e que roda omo parte do kernel, ao qual pode ser
arregado na forma de um modulo, exatamente omo se faz om varios \devi e drivers".
O novo servidor foi riado para resolver problemas e suprir de iên ias do servidor
velho, sendo de fato mais rapido e mais robusto. Entretanto, exatamente pelos mesmos
motivos ele e menos exvel e tem menos op ~oes do que o servidor antigo. Uma das
apa idades que ele n~ao implementa e a de re-exportar atraves de NFS, a partir de
uma determinada maquina, lesystem que esta maquina tenha montado remotamente
de outras maquinas, seja por NFS, seja por qualquer outro proto olo. N~ao se trata aqui
de que simplesmente ainda n~ao tenha havido tempo para a in lus~ao desta apa idade
adi ional no novo servidor, mas sim de uma de is~ao de n~ao in lu-la devido ao fato de
que ela interfere om a robustez de fun ionamento do servidor. Contatos om os autores
do odigo deixaram laro que n~ao se onhe e nenhuma forma robusta de in luir esta
apa idade e que n~ao ha no momento nenhuma inten ~ao de in lu-la.
Isto representa um problema para a arquitetura do PMC. Se, por um lado, queremos usar o novo servidor KNFSD no servidor de dis o, para exportar para os nos os
seus lesystems de sistema, pois temos aqui a ne essidade da maior robustez, e iên ia
e onabilidade possveis, por outro e ne essario que possamos fazer a re-exporta ~ao
para os nos dos homes dos usuarios e dos espelhos do kernel e da Debian a partir do
front-end, o que so e possvel fazer om o servidor velho, o UNFSD. De fato, este e
um dos motivos para a separa ~ao das fun ~oes de front-end e de servidor de dis o em
duas maquinas diferentes. A desvantagem deste sistema, em espe ial para PMCs muito
pequenos, e o a res imo que ele representa ao pre o dos equipamentos que n~ao est~ao
diretamente envolvidos nos al ulos numeri os. Ha, entretanto, outros motivos que le70
A.2. USO DE PLACAS DE REDE 3C905B/C
71
vam a separa ~ao entre o front-end e o servidor de dis o. Por exemplo, para sua maior
estabilidade opera ional e melhor que o servidor de dis o n~ao seja usado regularmente
pelos usuarios, o que inevitavelmente a onte e no front-end.
Assim, este on ito entre os dois servidores NFS a aba n~ao sendo um problema
muito serio. Caso se de ida unir as fun ~oes do front-end om as do servidor de dis o,
vai ser ne essario usar o UNFSD para todas as fun ~oes de exporta ~ao, o que torna o
fun ionamento dos nos menos robusto. Entretanto, esta de is~ao provavelmente so sera
tomada no aso de PMCs pequenos, nos quais esta pequena falta de robustez n~ao hega
a ser um problema muito grande. Na se ~ao 5.6 s~ao dis utidas algumas alternativas que
podem ajudar a resolver esta situa ~ao.
Uma alternativa interessante e o uso do PVM para passar entre os nos e o frontend mensagens om qualquer onteudo que os nos deveriam es rever nos ou ler dos
dis os, deixando as opera ~oes de leitura e es rita ao en argo do front-end que, por estar
na Internet, sempre pode montar os homes dos usuarios. Neste aso os usuarios n~ao
pre isariam nun a entrar interativamente nos nos, nem seria util que o zessem pois os
seus homes n~ao estariam disponveis. Entretanto, este esquema representa uma limita ~ao
indesejavel na exibilidade de uso do luster. A outra alternativa que existe e olo ar
um dis o de usuarios no front-end, o que torna o uso do sistema menos transparente para
os usuarios e ompli a o geren iamento do sistema, mesmo que se trate apenas de um
dis o temporario para a transferên ia dois dados para os homes externos. Re ordemos
aqui que a instala ~ao no front-end de servi os de dis o deve sempre ser a ompanhada
da substitui ~ao dos dis os IDE por dis os SCSI.
Est~ao sendo dis utidas na rede algumas alternativas mais avan adas para a resolu ~ao
deste problema, mas ja esta laro que n~ao apare era nenhuma solu ~ao nova a urto prazo.
Assim por enquanto as alternativas dis utidas a ima s~ao as alternativas que temos. E
laro que e sempre possvel que uma solu ~ao melhor apare a no futuro, logo quemos
atentos.
A.2 Uso de Pla as de Rede 3C905B/C

As pla as de rede que sugerimos em nosso exemplo, o modelo 3C905B da 3COM, s~ao
pla as de ex elente performan e e qualidade, por pre os bem razoaveis. Entretanto,
algumas destas pla as vêm da fabri a om um bug de ongura ~ao que, apesar de n~ao
afetar o fun ionamento normal da pla a no sistema, depois que ele ja esta bootado,
impede que o programa de boot remoto fun ione. Felizmente sabe-se omo orrigir este
bug, que e o que dis utiremos aqui: o \break-in" de uma pla a om este bug.
Para identi ar se a sua pla a apresenta este problema, basta tentar usa-la para um
boot remoto, olo ando nela um hip de boot remoto, montando-a em um sistema e
tentando bootar a maquina pela rede. Use para isto o terminal, pois vo ê tera de usar
um monitor VGA e uma unidade oppy. O sintoma do problema e que o sistema todo
trava durante o boot, enquanto tenta arregar o programa de boot que esta no hip, de
72
^
APENDICE
A. PROBLEMAS
forma que e ne essario usar o bot~ao de reset. N~ao hega a apare er nenhuma mensagem
do programa de boot na tela do omputador. Entretanto, pode-se prever se o problema
vai apare er pelo simples exame do fabri ante do hipset da pla a. Trata-se do hip
quadrado grande que ha na pla a. Ele pode ter sido produzido por uma de duas rmas,
a Broad om e a Lu ent. Se o fabri ante for Lu ent, sua pla a provavelmente tem o
problema.
Caso exista o problema, vamos ter de realizar uma sequên ia de opera ~oes para
orrigi-lo. A primeira sera re- ompilar o boot rom apropriado para esta pla a, que e
o 3 905b-tpo100.rom ou a sua vers~ao omprimida 3 905b-tpo100.lzrom, mas usando desta vez a have de ompila ~ao CFG 3C90X BOOTROM FIX, omo esta expli ado nas
do umenta ~oes do Etherboot. Trata-se simplesmente de des omentar uma linha do arquivo Makefile e de rodar make lean seguido de make no diretorio sr / da arvore de
ompila ~ao do Etherboot, que estamos assumindo esteja em
/usr/sr /etherboot-<vers>/sr /
Em seguida, e ne essario fazer um oppy bootavel om esta imagem, o que vo ê pode

fazer no mesmo diretorio, om o uso do omando
make 3 905b-tpo100.fd0
tendo olo ado, antes disso, um oppy vazio no drive fd0. Trata-se aqui de um oppy
omum de 1.4 MB. Se quiser, vo ê pode obter os roms ja ompilados para a pla a 3C905B
e uma imagem binaria do oppy de boot atraves da se ~ao C.3.
Feito o oppy, use-o para bootar o terminal, no qual ja deve ter sido olo ada a
pla a de rede problemati a. Devera apare er a mensagem de boot do programa e o
sistema deve tentar bootar pela rede, o que pode falhar pois esta pla a pode ainda n~ao
ter sido ongurada no servi o DHCP do servidor. Mas n~ao ha problema om isto, se o
programa ome ar a rodar o problema estara resolvido. Agora vo ê ja pode olo ar um
hip de boot remoto na pla a e usar ela normalmente para bootar um no. Guarde seu
oppy de boot espe ial para futuro uso em outras pla as, identi ando-o om um label
apropriado.
Quanto a nova pla a 3C905C, deve-se dizer que n~ao temos muita experiên ia direta
om ela. E possvel fazer ela fun ionar no sistema Linux, ja temos uma maquina om
Linux por aqui usando esta pla a sem problemas, mas o suporte para ela ainda n~ao e
parte integral dos kernels das vers~oes 2.2 e 2.4. Existem pat hes que podem ser apli ados
aos kernels das famlia 2.0 e 2.2 que in luem um novo driver para esta pla a, hamado
3 90x, enquanto as pla as anteriores s~ao suportadas pelo modulo 3 59x. Este modulo
anterior hega a fun ionar om a 3C905C, mas n~ao muito bem, re omendamos que ele
n~
ao seja usado om esta nova pla a. Os pat hes om o novo driver, que esta sob a
li en a GPL, podem ser obtidos a partir do site
http://support.3 om. om/infodeli/tools/ni /linuxdownload.htm
~ DE UM GRAVADOR DE EPROM
A.3. AQUISIC
AO
73
Sabe-se que o pat h do kernel 2.2.5 fun iona orretamente para o kernel 2.2.17. Os
outros asos ainda n~ao foram testados diretamente mas, omo ele simplesmente in lui um
novo driver, sem modi ar muito a estrutura ja existente na arvore do kernel, presumese que ele deva fun ionar para o kernel 2.2.18. Vo ê tambem pode obter o arquivo
tar omprimido om os pat hes e os respe tivos arquivos de do umenta ~ao atraves da
se ~ao C.3.
Tambem ja existe o suporte no Etherboot para esta nova pla a, se bem que ele ainda
e onsiderado \informal" pelos developers daquele projeto pois foi realizado numa base
experimental de tentativa e erro e n~ao om base na do umenta ~ao o ial da 3COM. Ao
que pare e o Etherboot fun iona bem om esta pla a, mas n~ao temos experiên ia direta
om isto. E laro que a situa ~ao esta mudando rapidamente e em breve deveremos ter
o novo modulo integrado ao kernel, bem omo suporte o ial no Etherboot. O que e
afortunado, pois e so uma quest~ao de tempo ate que as pla as anteriores desapare am
do mer ado e apenas este novo modelo esteja disponvel.
A.3 Aquisi ~ao de um Gravador de Eprom

A prin ipal di uldade do gravador de eprom e onseguir adquirir um por um pre o
razoavel. Simplesmente a har uma alternativa de aquisi ~ao para este equipamento ja
pode ser um problema, pois trata-se de equipamento relativamente pou o usado e que
n~ao e produzido em es ala muito grande. Quando se a ha um, frequentemente o pre o
e absurdamente alto.
Ate agora a melhor alternativa que a hamos foi na Rua Santa Egênia no entro
de S~ao Paulo, onde se on entra a maior parte do omer io de eletrôni a da idade.
O gravador mais simples que foi a hado era vendido por er a de R$ 500.00, enquanto
a lâmpada ultravioleta para o apagamento dos hips podia ser obtida por R$ 300.00.
Consideramos estes pre os muito altos, dada a simpli idade deste tipo de equipamento,
mas outros equipamentos semelhantes foram en ontrados por pre os muito maiores, na
faixa de R$ 2000.00 a R$ 3000.00 e ate mais.
Naturalmente, ha o fato de que este equipamento vai ser usado om muito pou a
frequên ia, mas a sua ausên ia ompleta simplesmente para o seu projeto. Grupos lo alizados proximos uns dos outros podem perfeitamente ompartilhar este equipamento.
Existe tambem uma rma que se propôs a es rever e vender os eproms, mas infelizmente des obrimos que ela pe ava pela falta de seriedade e desistimos de tentar resolver o
problema atraves dela imediatamente apos a primeira vez que nos trataram mal.
Ha uma rma em Pelotas, no Rio Grande do Sul, que vende uma modelo de gravador.
Trata-se da \Controni Sistemas Automati os", o modelo e o EP-98. O endere o da
rma na rede e
http://www. ontroni . om.br/
e o telefone e 273-8822. Tambem e possvel enviar orreio eletrôni o para
74
^
APENDICE
A. PROBLEMAS
ontroni ontroni . om.br
Segundo o que onsta na home page da rma e possvel adquirir o equipamento pelo
orreio. Infelizmente neste momento n~ao podemos dar nenhum depoimento adi ional
sobre esta rma pois apesar de uma tentativa logo antes das festas do nal do ano 2000,
ate agora ainda n~ao onseguimos estabele er ontato om eles, devido ao fato de que
nossa mensagem de orreio eletrôni o n~ao foi respondida. Tambem n~ao sabemos se o
aparelho in lui ou n~ao uma lâmpada de apagamento.
O uso de um equipamento deste tipo em geral impli a em bootar e usar o sistema
DOS na maquina. Dependendo da mar a e modelo pode ser possvel usar apenas um
oppy para bootar o DOS e outro oppy para rodar o programa que ontrola o dispositivo. Em outros asos pode ser ne essario ter um dis o rgido ou parti ~ao de dis o rgido
disponvel para a instala ~ao do DOS e do programa de ontrole. E por este motivo que
sugerimos a olo a ~ao de um segundo dis o IDE no terminal. Pode ser que seja possvel
rodar os programas de ontrole dentro do emulador dosemu do Linux, mas isto n~ao foi
tentado ate agora.
Ha uma altarnativa que envolve o uso de hips EEPROM, que podem ser apagados
eletroni amente. Existem na do umenta ~ao do projeto Etherboot referên ias a um
projeto para se montar um gravador deste tipo, que e ligado a porta paralela do terminal
e que pode ser utilizado no Linux atraves de software que esta disponvel livremente.
Ha, entretanto, a limita ~ao de que este gravador, em sua forma original, so grava hips
de ate 64 Kbits, ou seja, 8 KB, que s~ao muito pequenos para os roms que nos interessam
do projeto Etherboot. Os hips deste tipo ustam aproximadamente R$ 7.00 ada um.
Este tipo de hip de boot tem as vantagens de pres indir da lâmpada ultravioleta para o
apagamento, de fun ionar inteiramente no Linux e de poder es rever hips para qualquer
tipo pla a de rede, simplesmente substituindo os EPROMs tradi ionais.
A montagem do gravador pode ser realizada fa ilmente por alguem que tenha um
mnimo de experiên ia om montagens de eletrôni a e a aquisi ~ao das pe as usta apenas
er a de R$ 200.00. Um destes gravadores esta sendo montado atualmente pelo pessoal
dos laboratorios didati os do IFUSP. Existem tambem esfor os em andamento no IFUSP
para estender este projeto para hips de maior apa idade, pois pre isamos para os roms
do Etherboot de hips de pelo menos 16 KB, preferen ialmente de 32 KB, mas eles est~ao
apenas ome ando. Quando estes esfor os tiverem dado frutos ser~ao reportados aqui na
sua ntegra.
Uma alternativa que evitaria de todo a ne essidade da aquisi ~ao de um gravador
de eprom seria o uso de hips de \ ash-eprom", os quais s~ao suportadas pelas pla as
3C905, 3C905B e 3C905C, veja o omentario na se ~ao D.2.3. Este esquema e de longe
o mais onveniente do ponto de vista opera ional, mas tem a desvantagem de so estar
disponvel, neste momento, para estas pla as da 3COM. Alem disso, tivemos di uldades
de obter estes hips no mer ado na ional.
A.4. SOBRE A QUALIDADE DO HARDWARE
75
A.4 Sobre a Qualidade do Hardware

Um problema que podera ser en ontrado om alguma frequên ia e o da ma qualidade
dos equipamentos e pe as adquiridos. Ao ontrario do que pare e ser a ideia mais
popularmente disseminada, o nvel geral de qualidade de pe as de omputador n~ao e
assim t~ao alto hoje em dia. Com a massi a ~ao da produ ~ao de omputadores o fato e
que, assim omo os pre os, a qualidade tambem aiu, histori amente, se bem que muito
menos que os pre os.
O uso altamente disseminado de um sistema opera ional que leva o usuario a en arar
travamentos e reboots omo parte normal da opera ~ao de um omputador, bem omo
que ignora boa parte das apa idades de hardware de uma grande parte das maquinas,
ertamente ontribui para isto. Por um lado, os travamentos onstantes do sistema
opera ional mas aram possveis problemas que existam om o hardware, de forma que
os usuarios passam a n~ao re lamar tanto da qualidade deste hardware. Por outro lado,
o fato de que o sistema n~ao faz uso ompleto do hardware tambem tende a mas arar
problemas que existam nele. A s vezes o Linux e riti ado omo mais sus eptvel a
problemas de hardware. Isto de fato a onte e e e ausado pelo fato de que o Linux tenta
usar todas as apa idades do hardware em sua maxima extens~ao. E laro que pore isto
mesmo ele permite um ontrole muito maior e mais ompleto deste hardware.
De qualquer forma, a mudan a onstante e rapida da te nologia, juntamente om a
ne essidade de se fabri ar pe as em grande quantidade, olo a um grande stress sobre os
fabri antes, de forma que frequentemente saem, mesmo das melhores fabri as, modelos
om defeitos e de iên ias. Muito bem, o que podemos fazer a respeito disto? Bem,
felizmente trata-se de equipamento digital e, na maior parte das vezes os defeitos tambem
s~ao digitais em sua natureza, de forma que, om su iente trabalho de detetive e muita
pa iên ia, podem ser identi ados e isolados. Desta forma muitas vezes ainda e possvel
utilizar a pe a ou equipamento que apresenta um bug de hardware, talvez om algumas
limita ~oes.
So para dar um exemplo, uma vez des obrimos que ertas motherboards ontinham
um defeito no ontrolador do mouse PS/2. Se o dispositivo fosse a essado, havia imediatamente o travamento ompleto da maquina. Uma vez identi ado o problema, o que
de fato requer uma erta experiên ia e pa iên ia innita, bastou desativar o dispositivo
no setup das maquinas, retirar do kernel do Linux o driver orrespondente e o Linux
passou a rodar de forma ompletamente estavel nos equipamentos. Como os mouses
que estava sendo utilizados n~ao era do tipo PS/2, na verdade o in idente n~ao ausou
nenhuma limita ~ao importante naquele aso.
Enquanto forem adquiridos equipamentos relativamente padronizados e de mar as
bem onhe idas, tais omo os CPUs, pla as SCSI e pla as de rede que men ionamos
em nosso exemplo, os problemas deve ser mnimos. Outras pe as s~ao frequentemente
de fabri antes mais dif eis de se determinar omo, por exemplo, unidades DIMM de
memoria RAM, aso no qual deve-se simplesmente testar ada pe a adquirida quando
elas s~ao re ebidas do forne edor. Mas os problemas mais frequentes a onte em om
76
^
APENDICE
A. PROBLEMAS
dis os, gabinetes e motherboards, mais ou menos nesta ordem, bem omo om pe as
baratas mas n~ao por isto menos importantes omo mouses e te lados. Pla as de vdeo
e de som tambem podem ser problemati as para fun ionamento no Linux, mas neste
aso o problema e outro: nestes asos pla as novas est~ao sendo lan adas om frequên ia,
sempre om drivers do fabri ante apenas para o sistema opera ional que monopoliza o
mer ado. Assim, pode demorar algum tempo para que apare am drivers apropriados
no Linux, que fa am estas pe as desempenharem maximalmente as suas fun ~oes.
No aso dos dis os IDE deve-se tentar adquirir dis os das mar as IBM ou Fujitsu,
que s~ao as melhores, seguidas de Quantum e Seagate. Para dis os SCSI, as melhores
mar as hoje s~ao a IBM e a Quantum, seguidas de Seagate. Os dis os SCSI de topo
de linha s~ao usualmente bem mais onaveis do que a media. Note-se, entretanto que
estas re omenda
~
oes mudam om o tempo, em tempos passados elas teriam sido bem
diferentes. De qualquer foram, e sempre bom lembrar que dis os magneti os s~ao pe as
me ani amente sensveis e frageis, pois fazem uso de me âni a na de alta pre is~ao e
seus dis os rodam em altas velo idades. Deve-se tomar parti ular uidado om hoques
me âni os, em espe ial enquanto os dis os est~ao ligado e em pleno fun ionamento. Ao
re eber seus dis os ertique-se de que eles foram entregues bem embalados, em aixas
om amadas grossas de material absorvente de hoques, pois eles podem fa ilmente ser
dani ados no transporte.
Os problemas om os gabinetes baratos e que s~ao fra os, deformam-se fa ilmente e
em geral est~ao um pou o fora dos padr~oes de dimens~ao orretos. Com isto as pla as
muitas vezes n~ao se en aixam direito em seus slots, problemas de ontato s~ao frequentes
e o resultado e muito fragil, qualquer movimento da aixa pode ter onsequên ias serias.
N~ao se deve jamais e onomizar nos gabinetes, ertique-se de que vo ê tem gabinetes
da melhor qualidade possvel para o front-end, o servidor e o terminal. Um gabinete
bom pode ustar, digamos, de R$ 150.00 a R$ 600.00, dependendo do tamanho, em vez
de R$ 50.00 a R$ 150.00, mas de qualquer forma isto e muito pou o se omparado om
o pre o ompleto da maquina, enquanto o pre o de um mau gabinete pode ser alto em
termos dos problemas que pode ausar. Sem ontar que eles s~ao frequentemente mal
onstrudos internamente, om muitas pontas e arestas ortantes nas quais vo ê podera
fa ilmente se ferir ao tentar lidar om eles. As melhores mar as de gabinete disponveis
no mer ado na ional s~ao a Enlight e a Karrie.
No aso das motherboards, as op ~oes que temos no mer ado na ional s~ao, em geral,
pou as. Como a quest~ao da mar a da motherboard raramente e uma preo upa ~ao do
onsumidor, tendemos a ter pou as es olhas. De qualquer forma, o fato e que motherboards de mar as onhe idamente melhores s~ao substan ialmente mais aras e, no aso
dos nos, podem omprometer o or amento do PMC. Assim re omendamos a aquisi ~ao
de uma motherboard de boa mar a omo, por exemplo, a ASUS ou a Intel, no aso do
servidor. Para as demais maquinas, que ter~ao todas a mesma motherboard, deve-se simplesmente adquirir a que for mais barata, desde que ela satisfa a as ondi ~oes te ni as
mnimas para fun ionar om o pro essador e a memoria que vo ê es olheu. E laro que,
A.4. SOBRE A QUALIDADE DO HARDWARE
77
quando se for adquirir um numero grande de motherboards, e uma boa ideia testar uma
primeiro, por exemplo durante a montagem do front-end, soli itando uma emprestada
ao forne edor para este m, omo ondi ~ao para a aquisi ~ao de todo o lote.
Apêndi e B
Or amentos
Apresentamos neste apêndi e or amentos aproximados para a aquisi ~ao de hardware
para ada um dos omponentes do PMC, na forma omo ada um deles foi des rito ao
longo do do umento, sem prever quaisquer integra ~oes de fun ~oes entre os elementos
nem dos elementos om os servidores de dis o de home dos grupos usuarios. Caso
se pretenda fazer este tipo de jun ~ao de omponentes para redu ~ao dos ustos totais,
estes or amentos devem ser revistos de a ordo om as modi a ~oes que se pretenda
implementar.
Damos aqui as re eitas espe as que estamos usando para montar um sistema deste
tipo, in luindo mar as, modelos e pre os de ada pe a. Estes pre os e as dis rimina ~oes
te ni as s~ao baseados em nossa experiên ia lo al om um prototipo de 6 nos, montado
entre o nal do ano 2000 e o in io do ano 2001. Os pre os foram arredondados para
uma pre is~ao maxima de R$ 50.00.
Todos os pre os apresentados s~ao do mer ado lo al em S~ao Paulo, SP, em Reais, na
epo a men ionada a ima. Adapta ~oes e ajustes dos detalhes podem ser ne essarios tanto
devido ao passar do tempo quanto a realiza ~ao de projetos deste tipo em outras regi~oes
do pas. Observe-se que alguns dos pre os omo, por exemplo, o da memoria RAM, s~ao
muito volateis mesmo no mer ado interna ional, independentemente das ondi ~oes do
nosso mer ado lo al, que tambem ontribui om a sua propria volatilidade.
Considerando-se omo exemplo um PMC de 21 nos, om front-end e servidor separados, o valor total do investimento seria de er a de R$ 53000.00. E bom lembrar
que deste valor er a de R$ 15000.00 e um investimento ini ial xo, que n~ao pre isa ser
repetido enquanto se amplia o PMC de er a de 20 para quase 100 nos. Assim, este
investimento e melhor des rito omo tendo o valor R$ 15000.00 + R$ 38000.00, onde
apenas a segunda parte e aproximadamente propor ional ao numero de nos.
78
B.1. FRONT-END
79
B.1 Front-End
Em termos da es olha das pe as, o front-end esta ongurado omo uma maquina intermediaria entre um servidor e um no. N~ao esta in ludo um segundo dis o que eventualmente pode ser ne essario para a instala ~ao de um espelho de software. O pre o total e
de er a de R$ 2900.00.
Des ri ~ao da pe a

Q. P. uni. P. tot.
Motherboard mar a Asus para pro essador K7
1 500.00 500.00
Pro essador Athlon K7 de 800 MHz
1 450.00 450.00
DIMM de memoria SDRAM de 256 MB e 133 MHz 2 400.00 800.00
Pla a de rede 3COM modelo 3C905B
2 150.00 300.00
Dis o IDE de 6 GB
1 150.00 150.00
Fonte ATX de 300 W
1 50.00 50.00
Te lado padr~ao Ameri ano
1 50.00 50.00
Mouse de três bot~oes
1 50.00 50.00
Unidade oppy de 1.44 MB
1 50.00 50.00
Pla a de vdeo AGP de 4 MB
1 50.00 50.00
Monitor SVGA de 14"
1 150.00 150.00
Gabinete ATX midi-tower de boa qualidade
1 250.00 250.00
B.2 Servidor
O servidor esta ongurado om pe as de primeira qualidade na parte que interessa ao
papel que ele ira desempenhar. Para PMCs muito grandes pode ser ne essario olo ar
mais de um servidor. O pre o total e de er a de R$ 5500.00.
80
^
APENDICE
B. ORC
AMENTOS
Des ri ~ao da pe a

Q. P. uni. P. tot.
Motherboard mar a Asus para pro essador K7 1 500.00 500.00
1 450.00 450.00
DIMM de memoria SDRAM de 256 MB e 2 400.00 800.00
133 MHz
1 150.00 150.00
Fonte ATX de 300 W
1 50.00 50.00
Pla a PCI SCSI Adapte 2940-U160 de 160 1 500.00 500.00
MBps
Gabinete Enlight modelo 8900, tipo ATX full 1 650.00 650.00
tower, om 7 baias externas de 5-1/4"
Dis o SCSI de 9 GB e 160 MBps
2 1000.00 2000.00
1 50.00 50.00
1 50.00 50.00
1 50.00 50.00
1 50.00 50.00
Monitor VGA de 14"
1 150.00 150.00
B.3 Terminal
O pro essador e a memoria RAM s~ao iguais aos dos nos, om o a res imo de dois dis os
lo ais e de um onsole SVGA om alta resolu ~ao, que pode fun ionar om 1280960
pixels. Para PMCs grandes pode ser de interesse olo ar um monitor ainda maior, de
21", para fun ionar em modo 16001200. O pre o total e de er a de R$ 2900.00.
Des ri ~ao da pe a
Q. P. uni. P. tot.
Motherboard mar a Digitron modelo EAAKS
1 350.00 350.00
1 450.00 450.00
1 150.00 150.00
Dis o IDE de 6 GB
2 150.00 300.00
Fonte ATX de 300 W
1 50.00 50.00
1 50.00 50.00
1 50.00 50.00
1 50.00 50.00
1 100.00 100.00
Monitor SVGA de 17"mar a LG modelo 77i ou 1 600.00 600.00
775n
Gabinete ATX mini-tower de boa qualidade
1 150.00 150.00
Unidade ZIP IDE, interna, de 100 MB
1 150.00 150.00

B.4. NO
81
B.4 No
Trata-se de um pro essador Athlon K7 de 800 MHz om 256 MB de RAM om desempenho real de aproximadamente 250 M ops. A riterio da es olha da motherboard e
baseado em pre o, a menos do fato de que deve-se testar o desempenho om ela antes
de adquirir em grande quantidade. O pre o de um no e de er a de R$ 1400.00. Para
uma maquina de 21 nos teramos um pre o total de er a de R$ 30000.00.
Des ri ~ao da pe a
Q. P. uni. P. tot.
Motherboard mar a Digitron modelo EAAKS
1 350.00 350.00
1 450.00 450.00
1 150.00 150.00
Fonte ATX de 300 W
1 50.00 50.00
A motherboard do no para o pro essador K7 pode ser qualquer uma que use o hipset
VIA KX-133, in luindo os hips VIA-8371 e VIA-VT82C686A ou, de fato, qualquer outro
hipset fabri ado para o tipo de pro essador que se esta usando. A motherboard listada
tem a apa idade de ongurar os dois DIMMs de memoria RAM em interleave, o que
da um aumento de desempenho de er a de 5 % para o aso de datasets grandes.
Em todos os asos os pro essadores deve ser adquirido junto om um dissipador de
boa qualidade, om ventoinhas e um sensor, que serve para monitorar a temperatura
do CPU e a velo idade de rota ~ao das ventoinhas do dissipador. A presen a do sensor
pode ser determinada veri ando-se que s~ao usados os três os do one tor de for a
das ventoinhas do dissipador, n~ao apenas dois os. Vo ê tambem vai pre isar de pasta
termi a para montar o dissipador no CPU. Esta pasta termi a e em geral de or bran a e
pode ser en ontrada em lojas de omponentes de eletrôni a, em pequenos potes plasti os.
B.5 Equipamento de Rede

Es olhemos um equipamento da mar a 3COM, linha SuperSta k; trata-se de um Swit h 3300 XM (part number 3C16985) om 24 portas de 100 Mbps e possibilidade de
estaqueamento de ate 4 unidades atraves de abos matrix de baixo usto (R$ 300.00),
resultando efetivamente em swit hes om maiores numeros de portas, que pode ir ate
96 sem mudan as te ni as.
O pre o do modelo 3300 XM e R$ 3000.00 para ada unidade de 24 portas, sem o
abo matrix. O proximo modelo e o 3300 TM, que tem, alem da porta matrix, tem
uma porta TP de 1 Gbps. O pre o e de er a de R$ 4000.00. Pode-se tambem obter o
modelo 3300 MM, que alem de tudo isso tem um hub matrix de quatro portas interno,
om um pre o da ordem de R$ 6000.00.
Um sta k de quatro swit hes om um MM, e três XM sai por er a de R$ 15000.00.
Um sta k om um MM, um TM e dois XM sai por er a de R$ 16000.00. Como para
82
^
APENDICE
B. ORC
AMENTOS
ome ar vamos ter apenas uma unidade 3300 XM, o pre o total para este tem e de
er a de R$ 3000.00.
B.6 No-breaks
O no-break para o front-end, servidor, terminal e rede deve ser um Exide de 2 KVA,
ustando aproximadamente R$ 4000.00. Ja os no-breaks para os nos podem ser de um
modelo bem simples, om uma unidade de 1 KVA a 1.5 KVA para ada 6 a 8 nos,
ustando er a de R$ 600.00 a R$ 700.00 ada uma. Para um sistema de 21 nos seriam
ne essarios três destes no-breaks, de forma que o pre o total para este tem e de er a
de R$ 6000.00
B.7 Condi ionadores de Ar

Os pre os aproximados dos aparelhos s~ao R$ 1600.00 para o de 21000 BTU e R$ 2000.00
para o de 30000 BTU. O pre o e aproximadamente linear om a potên ia, tendendo a
air um pou o para equipamentos maiores. Para um PMC de 21 nos, ne essitaremos
de er a de 10500 BTU para os nos e de 2000 BTU para os servidores, perfazendo um
total de 12500 BTU, que pode ser forne ido onfortavelmente por um equipamento de
21000 BTU. Segue que o pre o total para este tem e de er a de R$ 1600.00.
B.8 Estante para Montagem dos Nos

Trata-se de uma estante modular de pinho da mar a Lundia Willo, om prateleiras
de 28 m de profundidade e 100 m de largura (de entro a entro dos montantes
laterais), om montantes laterais de 209 m de altura. Cada modulo da estante deve ter
11 prateleiras e pode abrigar ate 20 nos. As prateleiras s~ao ajustaveis nos montantes de
5 em 5 m e ser~ao olo adas de 20 em 20 m para abrigar os nos. Elas tambem podem
ser olo adas de 10 em 10 m para abrigar equipamentos de rede.
Com montantes de 249 m de altura ada modulo omporta 13 prateleiras de 20 em
20 m e pode abrigar ate 24 nos, ou 22 nos se nos reservarmos a prateleira de baixo para
os no-breaks. O espa o adi ional pode ser usado para o swit h de rede. As estantes
tambem podem ser feitas na propria institui ~ao se ela dispuser das ondi ~oes para isto.
Seja qual for o aso, o pre o desta parte ertamente esta abaixo de R$ 1000.00.
B.9 Materiais Auxiliares

Tambem vai ser ne essario adquirir varios tens de pequena monta, tais omo pasta
termi a, interruptores miniatura, leds, spray limpa- ontatos, tas Hellermann e tas
B.9. MATERIAIS AUXILIARES
83
olantes, nenhuma das quais tem qualquer peso relevante no or amento. No aso da
pasta termi a um pequeno pote de er a de 50 g deve ser mais do que o su iente para
todos os pro essadores de nosso exemplo.
Em rela ~ao as tas Hellermann, devem ser adquiridas as de numeros 50 (grande) 30
(media) e 18 ou 20 (pequenas). As pequenas servem para amarra ~oes deli adas de os
dentro dos gabinetes as maquinas. As medias servem para a maior parte dos asos nos
gabinetes, bem omo para algumas situa ~oes om os abos de rede. As grandes servem
para os abos de rede e de for a dos nos e quaisquer outros asos que apare am.
Pode-se usar tas olantes dos dois lados, grossas omo o tipo que se usa em espelhos
retrovisores de arros, para prender as fontes e as motherboards nas prateleiras da
estante. Trata-se de um material espesso, bran o e um pou o esponjoso, que pode ser
adquirido em peda os omo os que s~ao usados nos espelhos retrovisores, ou em rolos.
Os abos de rede TP devem ser de ategoria 5 e podem ser adquiridos prontos ou
feitos na propria institui ~ao, para o que se usa um ali ate rimpador espe ial para se
olo ar os one tores nas pontas dos abos. Se for ne essario fazer muitos abos, deve
sair mais em onta omprar o ali ate e fazer os abos. Trata-se de uma ferramenta
util de forma geral numa rede lo al, de forma que e possvel que ja exista um em sua
institui ~ao, verique. Os abos de rede podem ser do tipo rgido, en apados em azul,
que e mais barato e de melhor desempenho.
Apêndi e C
Congura ~ao
Apresentamos neste apêndi e uma bibliote a de arquivos que ser~ao uteis na instala ~ao,
opera ~ao e manuten ~ao de seu PMC. Est~ao in ludos arquivos de ongura ~ao de ada
um dos omponentes do PMC, s ripts para a exe u ~ao de tarefas espe as, listas de
pa otes e arquivos de ongura ~ao do kernel. Este apêndi e n~ao ontem os arquivos em
si, mas apenas uma des ri ~ao urta da fun ~ao de ada um e as referên ias aos hyperlinks
apropriados da WWW.
Todos os arquivos est~ao disponveis na WWW nas URLs indi adas. Caso vo ê
esteja lendo isto em papel e queira poupar tempo na digita ~ao de URLs, lembre-se de
que existe uma vers~ao em HTML deste do umento, na qual todos os links s~ao ativos,
levando diretamente aos arquivos. Fa a uma opia desta vers~ao em sua maquina ou
a esse om o seu browser a vers~ao que e mantida na home page do PMC, no endere o:
http://latt.if.usp.br/pm /Howto/
Assim, sup~oem-se que vo ê use um browser da WWW para examinar os arquivos e

obter opias deles atraves da Internet. Vo ê tera, e laro, de ustomizar uma boa parte
destes arquivos para o seu PMC. Observe que, para poder a essar a Internet om um
browser rodando no terminal dentro da rede privada de um PMC, basta rodar o browser
no front-end, om a janela dire ionada para o display X11 do terminal.
C.1 Bibliote a de Arquivos de Congura ~ao

Nesta se ~ao apresentamos uma ole ~ao de arquivos de ongura ~ao que podem ser usados
para ongurar ada um dos quatro tipos de maquina envolvidos em um PMC. Os
arquivos podem ser obtidos na URL:
http://latt.if.usp.br/pm / onfigs/
84
~
C.1. BIBLIOTECA DE ARQUIVOS DE CONFIGURAC
AO
85
Est~ao in ludos aqui apenas os arquivos e s ripts que vo ê provavelmente tera de ustomizar, editando-os a m~ao. Outros arquivos s~ao ustomizados automati amente durante
a abertura e instala ~ao de pa otes de software, as vezes usando as respostas que vo ê
da as perguntas que s~ao feitas pelo sistema de instala ~ao.
C.1.1 Front-End
.rhosts de root: Fun ~ao: implementar ontrole de a esso de root sem password ao sis-
tema, permitindo desta forma o livre trânsito do usuarios administrativo dentro do

luster, bem omo o ontrole automati o de uma maquina por outra, por exemplo
para shutdown automati o no aso de queda de luz e para a opera ~ao de sistemas
de ba kup automati o.
Lo aliza ~ao: diretorio /root/.
/pm / onfigs/fend/.rhosts
auto.amnt: Fun ~ao: denir as montagens automati as dentro do diretorio /amnt/; sera
usado para a montagem dos espelhos.

Lo aliza ~ao: diretorio /et /autofs/.
/pm / onfigs/fend/auto.amnt
auto.home: Fun ~ao: denir as montagens automati as dentro do diretorio /home/;
sera usado para a montagem dos homes dos usuarios.

/pm / onfigs/fend/auto.home
auto.master: Fun ~ao: denir a lista de diretorios onde ser~ao feitas montagens au-
tomati as.
Lo aliza ~ao: diretorio /et /.
/pm / onfigs/fend/auto.master
exports: Fun ~ao: ongurar as exporta ~oes de NFS, ou seja, os diretorios que poder~ao
ser montados remotamente por outras maquinas; e usada tanto para o UNFSD
quanto para o KNFSD.
/pm / onfigs/fend/exports
fstab: Fun ~ao: dis riminar os lesystems que podem ser montados e quais devem ser
montados durante o boot; a montagem de NFS que apare e e a do espelho do projeto LinORG, que so sera usada em situa ~oes espe iais, pois em geral vamos usar
86
^
~
APENDICE
C. CONFIGURAC
AO
o autofs para fazer a sua montagem automati a; este arquivo tambem determina
que sistemas lo ais de arquivos ser~ao veri ados durante o boot e em que ordem.
/pm / onfigs/fend/fstab
hosts: Fun ~ao: implementar uma base de dados sobre os nomes e numeros dos hosts
que existem; deve onter todas as entradas, n~ao so aquelas referentes ao proprio
host, pois elas ser~ao servidas as outras maquinas atraves do NIS.
/pm / onfigs/fend/hosts
hosts.allow: Fun ~ao: implementar ontrole de a esso ao front-end; este arquivo, que
e lido em primeiro lugar, determina aqueles hosts dos quais s~ao a eitas onex~oes
de rede atraves do daemon inetd e de outros daemons de rede; numa losoa
de a esso \mostly losed" este arquivo estara aberto apenas para aqueles hosts
autorizados.
/pm / onfigs/fend/hosts.allow
hosts.deny: Fun ~ao: implementar ontrole de a esso ao front-end; este arquivo, que e
lido em segundo lugar, determina aqueles hosts dos quais n~ao s~ao a eitas onex~oes
de rede atraves do daemon inetd e de outros daemons de rede; numa losoa de
a esso \mostly losed" este arquivo estara ompletamente fe hado.
/pm / onfigs/fend/hosts.deny
hosts.equiv: Fun ~ao: implementar ontrole de a esso sem password ao sistema, per-
mitindo desta forma o livre trânsito dos usuarios e das liga ~oes PVM dentro do
luster; podem ser usados nele netgroups.
/pm / onfigs/fend/hosts.equiv
interfa es: Fun ~ao: ongurar as duas redes nas quais o front-end esta, a LAN e a do
PMC; trata-se da forma atual de fazer isto.

Lo aliza ~ao: diretorio /et /network/.
/pm / onfigs/fend/interfa es
issue: Fun ~ao: denir a mensagem de wel ome para logins no sistema atraves do on-
sole.
~
AO
87

/pm / onfigs/fend/issue
issue.net: Fun ~ao: denir a mensagem de wel ome para logins no sistema atraves da
rede.
/pm / onfigs/fend/issue.net
lilo. onf: Fun ~ao: ongurar o boot do sistema a partir do dis o rgido, permitindo a
passagem de parâmetros para o kernel.

/pm / onfigs/fend/lilo. onf
lilo.msg: Fun ~ao: denir a mensagem de boot.
/pm / onfigs/fend/lilo.msg
netgroup: Fun ~ao: denir grupos de maquinas e grupos de usuarios em uma rede, para
ns de he agem de autoriza ~ao atraves do sistema NIS; pode-se denir regras de

autoriza ~ao para todo um grupo deste tipo.
/pm / onfigs/fend/netgroup
network: Fun ~ao: s ript exe utavel para ongurar as duas redes nas quais o front-end
esta, a LAN e a do PMC; trata-se da forma antiga de fazer isto.

Lo aliza ~ao: diretorio /et /init.d/.
/pm / onfigs/fend/network
nfs-server: Fun ~ao: s ript exe utavel para ini iar os daemons de NFS quando se esta
usando o UNFSD; deve ser olo ada neste arquivo a op ~ao que permite a reexporta ~ao de lesystems.
/pm / onfigs/fend/nfs-server
ntp. onf: Fun ~ao: ongurar o sistema NTP de sin roniza ~ao de relogios atraves da
rede; dene que servidor vai ser usado.

/pm / onfigs/fend/ntp. onf
88
^
~
APENDICE
C. CONFIGURAC
AO
sour es.list: Fun ~ao: ongurar os sites de onde o programa apt-get vai puxar pa otes
de software para instala ~ao no sistema.

Lo aliza ~ao: diretorio /et /apt/.
/pm / onfigs/fend/sour es.list
syslog. onf: Fun ~ao: ongurar o sistema de logs do sistema.
/pm / onfigs/fend/syslog. onf
yp. onf: Fun ~ao: ongurar um liente NIS, denindo qual e o servidor e qual e o
domnio aos quais o sistema deve se ligar; note que o proprio servidor e tambem
um liente neste sistema.
/pm / onfigs/fend/yp. onf
ypserv.se urenets: Fun ~ao: ongurar o a esso a um servidor NIS, denindo que
maquinas e redes podem ser a eitas omo lientes.

/pm / onfigs/fend/ypserv.se urenets
C.1.2 Servidor

/pm / onfigs/serv/.rhosts
usada para a montagem dos espelhos.

/pm / onfigs/serv/auto.amnt

/pm / onfigs/serv/auto.home
~
AO
89
tomati as.
/pm / onfigs/serv/auto.master
dh pd. onf: Fun ~ao: implementar uma base de dados om informa ~oes sobre os nos,
para permitir o boot deles atraves da rede.

/pm / onfigs/serv/dh pd. onf
/pm / onfigs/serv/exports
/pm / onfigs/serv/fstab
que existem; deve onter as entradas referentes ao proprio host e outras que sejam
ne essarias durante o boot, as demais ser~ao obtidas atraves do sistema NIS.
/pm / onfigs/serv/hosts
/pm / onfigs/serv/hosts.equiv
inetd. onf: Fun ~ao: ongurar o sistema de daemons de rede, que s~ao ini iados pelo
super-daemon inetd; sera usada para ativar o servi o de TFTP que e usado par
ao boot remoto dos nos.
90
^
~
APENDICE
C. CONFIGURAC
AO

/pm / onfigs/serv/inetd. onf
interfa es: Fun ~ao: ongurar a rede na qual o sistema esta; trata-se da forma atual
de fazer isto.
/pm / onfigs/serv/interfa es
sole.
/pm / onfigs/serv/issue
rede.
/pm / onfigs/serv/issue.net

/pm / onfigs/serv/lilo. onf
/pm / onfigs/serv/lilo.msg
network: Fun ~ao: s ript exe utavel para ongurar a rede na qual o sistema esta;
trata-se da forma antiga de fazer isto.

/pm / onfigs/serv/network

/pm / onfigs/serv/ntp. onf
~
AO
91

/pm / onfigs/serv/sour es.list
/pm / onfigs/serv/syslog. onf
yp. onf: Fun ~ao: ongurar de um liente NIS, denindo qual e o servidor e qual e o
domnio aos quais o sistema deve se ligar.

/pm / onfigs/serv/yp. onf
C.1.3 Terminal

/pm / onfigs/term/.rhosts

/pm / onfigs/term/auto.amnt
tomati as.
/pm / onfigs/term/auto.master
/pm / onfigs/term/exports
92
^
~
APENDICE
C. CONFIGURAC
AO
/pm / onfigs/term/fstab
/pm / onfigs/term/hosts
/pm / onfigs/term/hosts.equiv
de fazer isto.
/pm / onfigs/term/interfa es
sole.
/pm / onfigs/term/issue
rede.
/pm / onfigs/term/issue.net

/pm / onfigs/term/lilo. onf
~
AO
93
/pm / onfigs/term/lilo.msg

/pm / onfigs/term/network

/pm / onfigs/term/ntp. onf

/pm / onfigs/term/sour es.list
/pm / onfigs/term/syslog. onf

/pm / onfigs/term/yp. onf
C.1.4 Nos

/pm / onfigs/node/.rhosts
94
^
~
APENDICE
C. CONFIGURAC
AO

/pm / onfigs/node/auto.amnt

/pm / onfigs/node/auto.home
tomati as.
/pm / onfigs/node/auto.master
/pm / onfigs/node/fstab
/pm / onfigs/node/hosts
/pm / onfigs/node/hosts.equiv
inittab: Fun ~ao: ongurar o programa init, que ontrola o omportamento geral do
sistema: portas de entrada e sada, run-levels, boot e shutdown, et . O que nos

interessa aqui e a ativa ~ao de programas getty ligados as portas seriais, de forma
a permitir o login no sistema atraves de terminais ASCII que estejam one tados
a elas.
~
AO
95

/pm / onfigs/node/inittab
de fazer isto.
/pm / onfigs/node/interfa es
sole.
/pm / onfigs/node/issue
rede.
/pm / onfigs/node/issue.net

/pm / onfigs/node/network

/pm / onfigs/node/ntp. onf

/pm / onfigs/node/sour es.list
/pm / onfigs/node/syslog. onf
96
^
~
APENDICE
C. CONFIGURAC
AO

/pm / onfigs/node/yp. onf
C.1.5 Usuario
.Xresour es: Fun ~ao: ontrole de re ursos do X11 para um determinado usuario. O
arquivo para o qual o link abaixo aponta ontem as linhas deste arquivo que
dizem respeito ao programa seyon, para ongurar o seu uso omo terminal para
o onsole serial dos nos.
Lo aliza ~ao: diretorio-home do usuario.
/pm / onfigs/user/seyon.Xresour es
C.2 Bibliote a de S ripts

Nesta se ~ao apresentamos uma ole ~ao de s ripts de shell para uso na opera ~ao e geren iamento do PMC. Os s ripts podem ser obtidos na URL:
http://latt.if.usp.br/pm /s ripts/
Em alguns asos vo ê tera de ustomizar estes programas para que eles atendam as
ne essidades parti ulares do seu PMC.
beep3: Fun ~ao: pis ar três vezes o led de beep quando o sistema termina de entrar em
modo single-user.
Lo aliza ~ao: diretorio /et /r .boot/ dos nos.
/pm /s ripts/beep3
beep5: Fun ~ao: pis ar in o vezes o led de beep quando o sistema termina de entrar
em modo multi-user.
Lo aliza ~ao: diretorio /et /init.d/ dos nos.
/pm /s ripts/beep5
hard-link- ommon-les-root: Fun ~ao: eliminar repeti ~oes de arquivos idênti os na
arvore de arquivos / dos nos.

Lo aliza ~ao: diretorio /pm / do servidor.
/pm /s ripts/hard-link- ommon-files-root
C.2. BIBLIOTECA DE SCRIPTS
97
hard-link- ommon-les-var: Fun ~ao: eliminar repeti ~oes de arquivos idênti os na
arvore de arquivos /var dos nos.

Lo aliza ~ao: diretorio /pm /var/ do servidor.
/pm /s ripts/hard-link- ommon-files-var
make-netboot-kernel: Fun ~ao: transformar um kernel do Linux num uni o kernel
bootavel atraves da rede, por qualquer um dos nos do PMC. Neste aso as ongura ~oes de rede de ada no ser~ao ompletamente passadas atraves do proto olo
DHCP e estar~ao no arquivo /et /dh pd. onf.
/pm /s ripts/make-netboot-kernel
make-netboot-kernels: Fun ~ao: transformar um kernel do Linux numa ole ~ao de
kernels bootaveis atraves da rede, um para ada no do PMC. Neste aso as ongura ~oes de rede de ada no estar~ao en odi adas dentro do \network boot blo k"
de ada kernel.
/pm /s ripts/make-netboot-kernels
mirror-kernel: Fun ~ao: fazer um espelho lo al do kernel do Linux; deve ser rodado
atraves do programa ron.

Lo aliza ~ao: diretorio /sft/bin/ do front-end.
/pm /s ripts/mirror-kernel
A entrada de rontab de root para este programa:

/pm /s ripts/mirror-kernel. rontab
mirror-debian: Fun ~ao: fazer um espelho lo al da parte prin ipal da distribui ~ao De-
bian; deve ser rodado atraves do programa ron.

/pm /s ripts/mirror-debian

/pm /s ripts/mirror-debian. rontab
mirror-debian-non-US: Fun ~ao: fazer um espelho lo al da parte da distribui ~ao De-
bian que envolve en ripta ~ao; deve ser rodado atraves do programa ron.
/pm /s ripts/mirror-debian-non-US
98
^
~
APENDICE
C. CONFIGURAC
AO
/pm /s ripts/mirror-debian-non-US. rontab
mirror-debian-se urity: Fun ~ao: fazer um espelho lo al da parte da distribui ~ao De-
bian que distribui updates de seguran a; deve ser rodado atraves do programa
ron.
/pm /s ripts/mirror-debian-se urity

/pm /s ripts/mirror-debian-se urity. rontab
myrror-root: Fun ~ao: fazer ba kups in rementais automati os e regulares de uma
ole ~ao de diretorios ontendo as ongura ~oes e os logs de um sistema.

Lo aliza ~ao: diretorio /root/bin/ de ada sistema.
/pm /s ripts/myrror-root

/pm /s ripts/myrror-root. rontab
njobs: Fun ~ao: mostrar a atividade de pro essamento intensivo em todos os nos de um
PMC.
Lo aliza ~ao: diretorio /usr/lo al/bin/ de todas as maquinas.
/pm /s ripts/njobs
xmulti-vmstat: Fun ~ao: rodar simultaneamente 24 instân ias do programa vmstat
para monitoramento da atividade nos sistemas, ada uma orrespondendo a um

no, numa tela de X11 do terminal; o onjunto de janelas abe em uma tela de
1280860 pixels. Com o fvwm ou outro sistema de janelas virtual pode-se ter
varias telas deste tamanho ao mesmo tempo, desde que haja su iente memoria
RAM no sistema. Este pequeno programa de shell pode fa ilmente ser ustomizado
para o tamanho da tela e para o numero de nos de seu PMC.
Lo aliza ~ao: diretorio /root/bin/ do terminal.
/pm /s ripts/xmulti-vmstat
xmulti-x onsole: Fun ~ao: rodar simultaneamente 24 instân ias do programa x onsole
para monitoramento das mensagens de erro nos sistemas, ada uma orrespondendo a um no, numa tela de X11 do terminal; o onjunto de janelas abe em uma tela
de 1280860 pixels. Com o fvwm ou outro sistema de janelas virtual pode-se ter
varias telas deste tamanho ao mesmo tempo, desde que haja su iente memoria
RAM no sistema. Este pequeno programa de shell pode fa ilmente ser ustomizado
para o tamanho da tela e para o numero de nos de seu PMC.
C.3. OUTROS ARQUIVOS E LISTAS
99

/pm /s ripts/xmulti-x onsole
xmulti-xload: Fun ~ao: rodar simultaneamente 24 instân ias do programa xload para
monitoramento da arga nos sistemas, ada uma orrespondendo a um no, numa

tela de X11 do terminal; o onjunto de janelas abe em uma tela de 1280860
pixels. Com o fvwm ou outro sistema de janelas virtual pode-se ter varias telas
deste tamanho ao mesmo tempo, desde que haja su iente memoria RAM no
sistema. Este pequeno programa de shell pode fa ilmente ser ustomizado para o
tamanho da tela e para o numero de nos de seu PMC.
/pm /s ripts/xmulti-xload
C.3 Outros Arquivos e Listas

Nesta se ~ao apresentamos listas de pa otes de software que devem ser instalados em
ada um dos omponentes do PMC, bem omo arquivos de ongura ~ao do kernel do
Linux apropriados para ada um deles, alem de outros arquivos. Os arquivos podem ser
obtidos a partir da URL:
As listas de pa otes podem ser usadas omo input do apt-get ou do dpkg para
instalar rapidamente todos eles, mas sugerimos que vo ê instale os pa otes aos pou os, onforme ada um deles for ne essario, de forma a ter tempo de aprender sobre a
utilidade de ada um deles.
Lista de pa otes importantes do front-end:

/pm /pa otes/fend.list
Lista de pa otes importantes do servidor:

/pm /pa otes/serv.list
Lista de pa otes importantes do terminal:

/pm /pa otes/term.list
100
^
~
APENDICE
C. CONFIGURAC
AO
Lista de pa otes importantes dos nos:

/pm /pa otes/node.list
Os arquivos de ongura ~ao podem ser lidos diretamente pelos programas de ongura ~ao do kernel, por exemplo pelo sistema de janelas ontendo menus que roda se
vo ê exe utar make x onfig na raiz da arvore de ompila ~ao do kernel. O mesmo pode
ser feito om o make menu onfig.
Arquivo de ongura ~ao do kernel do front-end:
Lo aliza ~ao: diretorio /usr/sr /linux/.

/pm /kernels/Config-2.2.18-fend
Arquivo de ongura ~ao do kernel do servidor:

/pm /kernels/Config-2.2.18-serv
Arquivo de ongura ~ao do kernel do terminal:

/pm /kernels/Config-2.2.18-term
Arquivo de ongura ~ao do kernel dos nos:

/pm /kernels/Config-2.2.18-node
Depois de ler estes arquivos atraves do make x onfig, vo ê pode per orrer os menus
e fazer quaisquer mudan as que sejam ne essarias antes de ompilar o kernel. Neste
aso es reva uma opia da nova ongura ~ao em um arquivo om um nome sugestivo e
guarde-o omo referên ia.
Listamos abaixo links para arquivos tar omprimidos e imagens binarias omprimidas de oppies para variadas nalidades.
Diretorio boot- oppy: Neste arquivo tar omprimido vo ê en ontrara todos os ar-
quivos que devem estar dentro do diretorio /pm /boot-floppy/.

/pm /tar+bin/pm boot-floppy.tgz
Floppy de boot: Neste arquivo, omprimido om o gzip, vo ê en ontrara uma ima-
gem binaria do oppy de boot do no virtual n0000, ontendo um kernel da vers~ao
indi ada.
/pm /tar+bin/boot-floppy-2.2.18.dd.gz
C.4. BIBLIOTECA DE DIAGRAMAS
101
Imagem ROM: Esta e uma imagem binaria, omprimida om o gzip, do rom para a
pla a de rede 3C905B.
/pm /tar+bin/3 905b-tpo100.rom.gz
Imagem LZROM: Esta e uma imagem binaria, omprimida om o gzip, do rom om-
primido para a pla a de rede 3C905B.
/pm /tar+bin/3 905b-tpo100.lzrom.gz
Floppy de bub-x: Neste arquivo, omprimido om o gzip, vo ê en ontrara uma
imagem binaria do oppy de boot om o rom de bugx para pla as de rede 3C905B.
/pm /tar+bin/etherboot 3 905b fix.dd.gz
O programa mknbi: Neste arquivo tar omprimido vo ê en ontrara todos os arquivos
relativos ao programa mknbi que devem ser instalados em seu sistema. O mknbi
utiliza a shell de programa ~ao perl, que vo ê tambem deve ter em seu sistema
mas que n~ao e problema pois ja existe na Debian. Para abrir este arquivo tar
vo ê deve primeiro ir para o diretorio /usr/lo al/ do servidor.
/pm /tar+bin/mknbi-1.0.tgz
Pat hes para a 3C905C: Neste link vo ê en ontrara um arquivo tar omprimido om
os pat hes para o kernel do Linux que in luem nele o novo driver 3 90x, ne essario
para a pla a de rede 3C905C. Ha pat hes para os kernels 2.0.36 e 2.2.5, bem omo
arquivos de do umenta ~ao.
/pm /tar+bin/3 90x-1.0.0i.tar.gz
C.4 Bibliote a de Diagramas

Apresentamos aqui alguns diagramas sobre oisas variadas.
Chip de Boot: O hip de boot eprom ou eeprom deve ser olo ado na posi ~ao erta
no soquete da pla a de rede. Ha um \not h" tanto no soquete quanto no hip, os
dois devem estar do mesmo lado. Alem disso, pode ser que o seu hip seja mais
urto do queo soquete, om menos pinos. Neste aso eles devem ser alinhados pelo
lado que n~ao tem o not h. Aqui esta um diagrama sobre isto:
102
^
~
APENDICE
C. CONFIGURAC
AO
CHIP DE BOOT
NOTCH
ALINHAR POR AQUI
SOQUETE DA
PLACA DE REDE
NOTCH
Apêndi e D
Re eitas
Apresentamos neste apêndi e re eitas detalhadas e espe as para todos os aspe tos
e ada uma das fases do projeto. Os detalhes das re eitas s~ao baseados em nossa
experiên ia lo al om um prototipo de 6 nos, montado entre o nal do ano 2000 e o
in io do ano 2001.
D.1 Re eitas de Montagem de Hardware

D.1.1 Ferramentas e Materiais Ne essarios
Para a montagem dos sistemas vo ê tera de dispor de uma pequena ole ~ao de ferramentas e de uma serie de materiais auxiliares. Quase todos os parafusos nos gabinetes
das maquinas ser~ao do tipo Philips, de forma que uma have Philips vai ser a ferramenta
de uso mais omum. E uma boa ideia ter duas delas disponveis, em espe ial se mais de
uma pessoa estiver envolvida na montagem das maquinas. Tambem vai ser ne essario
ter um ali ate de orte e algumas outras oisas. Aqui esta uma lista mais ou menos
ompleta:

Uma have Philips numero 1.

Duas haves Philips numero 2.
Uma have de fenda pequena.
Uma have de fenda media.
Um ali ate de orte.
Um ali ate de bi o no.
Um ali ate omum.
103
104

^
APENDICE
D. RECEITAS
Um ferro de solda de 20{30 W.

Uma pequena presilha de solda.
Um utter de lâmina tro avel.
Uma tesoura omum.
Uma lanterna de boa qualidade.
Uma extens~ao de for a de três pinos.
Quanto aos materiais que e bom ter a m~ao, podemos listar os seguintes:

Um rolo de o de solda na, para eletrôni a.

Fitas Hellerman de numeros 50, 30 e 18 ou 20.
Um rolo de ta isolante de boa qualidade.
Um pote pequeno de pasta termi a para dissipadores.
Duas ou três latas de spray limpa- ontatos.
Flanelas, al ool de limpeza e toalhas de papel.
Um rolo de ta repe e outro de ta durex.
Uma ou duas aixas de oppies de boa qualidade.
Tambem e bom ter disponvel um multmetro simples de uso geral. Para medidas de
onsumo de potên ia e ne essario ter um ampermetro-ali ate. Alem disso ha tambem
uma serie de pequenas pe as e de materiais que vo ê devera adquirir para apli a ~ao no
PMC, entre as quais podemos itar:

Leds de duas ores diferentes.

Interruptores miniatura de ontato momentâneo.
Cone tores DB-9 e/ou DB-25 om apas plasti as.
Varios metros de abo serial de pelo menos dois pares.
Cone tores ategoria 5 para abos de rede.
Cabos de rede UTP atergoria 5.
Pat h ords de rede ategoria 5.
D.1. RECEITAS DE MONTAGEM DE HARDWARE
105
Standard CMOS Features

Nome do Item
Alternativa em Efeito
Date and Time
IDE Primary Master
IDE Primary Slave
IDE Se ondary Master
IDE Se ondary Slave
Drive A
Drive B
Video
Halt On
(a erte pelo GMT)

(submenu: Auto)
(submenu: Auto)
(submenu: Auto)
(submenu: Auto)
1.44 M, 3.5 in
None
EGA/VGA
All Errors
Tabela D.1: Congura ~oes: Standard CMOS Features
Transistores BC548 ou similar.

Resistores de 10 K
e de 47 K
, 1/8 W.
Naturalmente, no aso de montagem de estantes de madeira no lo al ou de outras
atividades, ferramentas e materiais adi ionais provavelmente ser~ao ne essarios, de forma
que estas listas podem perfeitamente n~ao estar ompletas para o seu aso parti ular.
D.1.2 Congura ~ao Geral do Bios

Um dos problemas que sempre en ontramos ao montar e ongurar o hardware de uma
maquina e a ongura ~ao do setup da bios ou do CMOS da motherboard. Mostramos
nas tabelas desta se ~ao a ongura ~ao geral basi a valida para todos os omponentes
do PMC. Na proxima se ~ao listamos as ongura ~oes espe as para ada omponente,
mostrando apenas as diferen as em rela ~ao a esta ongura ~ao geral.
Trata-se aqui do \Award Modular Bios v6.00PG" da Award Software, que e en ontrado na motherbord Digitron para o K7. Entretanto, os nomes dos tens s~ao semelhantes
em outras motherboards e as es olhas feitas devem ser as mesmas. Observe-se que ha
alguns tens do menu prin ipal que n~ao devem ser usados de todo:
Load Fail-Safe Defaults
Load Optimized Defaults
Set Supervisor Password
Set User Password
106
^
APENDICE
D. RECEITAS
Advan ed BIOS Features

Nome do Item
Virus Warning
Disabled
CPU Internal Ca he
Enabled
External Ca he
Enabled
CPU L2 Ca he ECC Che king
Disabled
Qui k Power On Self Test
Enabled
First Boot Devi e
Floppy
Se ond Boot Devi e
HDD-0
Third Boot Devi e
CDROM
Boot Other Devi e
Disabled
Swap Floppy Drive
Disabled
Boot Up Floppy Seek
Enabled
Boot Up NumLo k Status
Off
Gate A20 Option
Fast
Typemati Rate Setting
Enabled
Typemati Rate (Chars/Se )
30
Typemati Delay (Mse )
250
Se urity Option
Setup
OS Sele tion for DRAM > 64 MB Non-OS2
Video Bios Shadow
Disabled
XXXXX-XXXXX Shadow
Disabled (todos)
Tabela D.2: Congura ~oes: Advan ed BIOS Features
Advan ed Chipset Features

Nome do Item
Bank 0/1 DRAM Timing
SDRAM Cy le Length
Bank Interleave
DRAM Page-Mode
Memory Hole
P2C/C2P Con urren y
Fast R-W Turn Around
System Bios Ca heable
Video Bios Ca heable
Video RAM Ca heable
AGP Aperture Size
AGP-4X Mode
AGP Driving Control
AGP Fast Write
K7 CLK CTL Sele t
OnChip USB Port 1/2
OnChip USB Port 3/4
USB Keyboard Support
OnChip Sound
OnChip Modem
CPU to PCI Write Buffer
PCI Dynami Bursting
PCI Master 0 WS Write
PCI Delay Ttansa tion
PCI#2 A ess #1 Retry
AGP Master 1 WS Write
AGP Master 1 WS Read
Memory Parity/ECC Che k
SDRAM Fast
SDRAM Fast
SDRAM Fast
Auto
Disabled
Enabled
Disabled
Enabled
Disabled
Disabled
Disabled
Disabled
256 M
Enabled
Auto
Disabled
Optimal
Disabled
Disabled
Disabled
Disable
Disable
Enabled
Enabled
Enabled
Enabled
Disabled
Disabled
Disabled
Disabled
Tabela D.3: Congura ~oes: Advan ed Chipset Features
107
108
^
APENDICE
D. RECEITAS
Integrated Peripherals

Nome do Item
OnChip IDE Channel0
OnChip IDE Channel1
Primary Master PIO
Primary Slave PIO
Se ondary Master PIO
Se ondary Slave PIO
Primary Master UDMA
Primary Slave UDMA
Se ondary Master UDMA
Se ondary Slave UDMA
IDE Prefet h Mode
Init Display First
IDE HDD Blo k Mode
Onboard FDD Controler
Onboard Serial Port 1
Onboard Serial Port 2
UART2 Mode
Onboard Parallel Port
Onboard Parallel Mode
Parallel Mode EPP Type
Onboard Lega y Audio
Enabled
Enabled
Auto
Auto
Auto
Auto
Auto
Auto
Auto
Auto
Enabled
AGP
Enabled
Enabled
3F8/IRQ4
2F8/IRQ3
Standard
378/IRQ7
EPP
EPP1.9
Disabled
Tabela D.4: Congura ~oes: Integrated Peripherals
109
Power Management Setup

Nome do Item
ACPI Fun tion
Power Management
Disabled
(submenu)
Power Management
HDD Power Down
Suspend Mode
ACPI Suspend Type
PM Control by APM
Video Off Option
Video Off Method
Modem Use IRQ
Soft-Off by PWRBTN
State After Power Failure
CPU Fan In Suspend
Wake Up Events
User Define
Disabled
Disabled
S1(POS)
Yes
Suspend -> OFF
V/H SYNC+Blank
N/A
Delay 4 Se
On
On
(submenu)
VGA
LPT & COM
HDD & FDD
PCI Master
PowerOn/Resume by Keyboard
PowerOn/Resume by PCI Card
PowerOn/Resume by LAN/Ring
PowerOn/Resume by RTCAlarm
IRQs A tivity Monitoring
OFF
NONE
OFF
OFF
Disabled
Disabled
Disabled
Disabled
(submenu:
Nome do Item
Nome do Item
OFF)
Tabela D.5: Congura ~oes: Power Management Setup
110
^
APENDICE
D. RECEITAS
PnP/PCI Conguration

Nome do Item
PnP OS Installed
Reset Configuration Data
Resour es Controled By
PCI/VGA Palette Snoop
Assign IRQ For VGA
Assign IRQ For USB
PCI Laten y Timer (CLK)
PCI Slot 1 Use IRQ No.
PCI Slot 4/5 Use IRQ No.
No
Disabled
Auto (ESCD)
Disabled
Disabled
Disabled
0
Auto
Auto
Auto
Auto
Tabela D.6: Congura ~oes: PnP/PCI Conguration
Frequen y/Voltage Control

Nome do Item
Auto Dete t DIMM/PCI Clk
CPU Host Clo k (CPU/PCI)
100/133 MHz Spread Spe trum
DRAM Clo k
Enabled
Default
Enabled
Host Clo k
Tabela D.7: Congura ~oes: Frequen y/Voltage Control
111
N~ao e ne essario olo ar passwords de setup em nenhuma das maquinas se elas arem
em algum lugar seguro, sem que pessoas n~ao-autorizadas tenham a esso aos seus onsoles. No aso dos nos, n~ao pode ser olo ada nenhuma password, pois estes omponentes
n~ao ter~ao um monitor VGA, de forma que n~ao seria possvel utilizar estas passwords de
qualquer forma. Em qualquer aso, se for usada uma password deve ser usada apenas
a de \Supervisor", valendo apenas para o setup da maquina. Tambem ha um tem do
menu prin ipal onde n~ao ha nada a ser feito:
PC Health Status
Os outros tens do menu prin ipal e as es olhas dentro dos sub-menus orrespondentes
s~ao os que est~ao nas tabelas de D.1 a D.7.
D.1.3 Congura ~oes Espe as de Cada Componente

Congura ~oes de BIOS do Front-End No front-end a ordem dos dispositivos de
boot deve ser esta:

Nome do Item
First Boot Devi e Floppy
Se ond Boot Devi e HDD-0
Third Boot Devi e LS/ZIP
Caso vo ê tenha dois DIMMs na maquina, em vez de um so, ative esta op ~ao:
Nome do Item Alternativa em Efeito
Bank Interleave 2 Bank
Caso vo ê tenha adquirido DIMMs apazes de trabalhar a 133MHz, ative esta

op ~ao:
DRAM Clo k
HCLK+33M
Congura ~oes de BIOS do Servidor No servidor a ordem dos dispositivos de boot
deve ser esta:
112
^
APENDICE
D. RECEITAS

Nome do Item
Se ond Boot Devi e SCSI
Third Boot Devi e Disabled
No servidor podemos desativar os drivers IDE:


Nome do Item
OnChip IDE Channel0
OnChip IDE Channel1
Disabled
Disabled

op ~ao:
DRAM Clo k
HCLK+33M
Congura ~oes de BIOS do Terminal No terminal a ordem dos dispositivos de boot
deve ser esta:

Nome do Item
Se ond Boot Devi e HDD-0
Third Boot Devi e CDROM
113


op ~ao:
DRAM Clo k
HCLK+33M
Congura ~oes de BIOS dos Nos No aso dos nos devemos desabilitar os dis os IDE:
Standard CMOS Features
Nome do Item
IDE Primary Master
IDE Primary Slave
IDE Se ondary Master
IDE Se ondary Slave
Halt On
(submenu:
(submenu:
(submenu:
(submenu:
No Errors
None)
None)
None)
None)
Nos nos a ordem dos dispositivos de boot deve ser a que segue; alem disso, deve-se
desabilitar o seek do oppy no boot:
Nome do Item
First Boot Devi e
Se ond Boot Devi e
Third Boot Devi e
Boot Up Floppy Seek
LAN
Floppy
HDD-0
Disabled
Nos nos podemos desativar os drivers IDE:
114
^
APENDICE
D. RECEITAS

Nome do Item
OnChip IDE Channel0
OnChip IDE Channel1
Disabled
Disabled
Power Management Setup

Nome do Item
Soft-Off by PWRBTN
Instant-Off
State After Power Failure Off

op ~ao:
DRAM Clo k
HCLK+33M
D.2 Re eitas de Instala ~ao de Software

D.2.1 Instala ~ao de um Espelho Lo al
Se sua institui ~ao ja tem um espelho em sua rede lo al, use-o. Se vo ê puder usar o
sistema de espelhamento do projeto LinORG, use-o. Caso ontrario, vo ê deve montar
um espelho lo al dos sites de distribui ~ao de software que interessam para este projeto
em alguma maquina da rede lo al da sua institui ~ao. O front-end do PMC pode ser
usado para isto mas, se for montado nele um espelho permanente de uso geral da rede
lo al da institui ~ao, sugerimos a tro a dos dis os IDE do front-end por dis os SCSI. Se
o espelho for apenas temporario, n~ao ha ne essidade da tro a.
Para instalar um espelho lo al do kernel do Linux e da distribui ~ao Debian, in luindo
apenas os pa otes binarios, oloque um segundo dis o no front-end, omo men ionado
na se ~ao 2.5. Use um dis o de no mnimo uns 4 GB, idealmente um de 6 GB ou mais. As
taxas de o upa ~ao de ada um dos espelhos neste momento s~ao dadas na tabela abaixo,
mas lembre-se de que eles tendem a aumentar om o tempo, se bem que lentamente.
Espelho
Tamanho (MB)
kernel
570
debian
2600
debian-non-US
20
debian-se urity
140
Total
3330
~ DE SOFTWARE
D.2. RECEITAS DE INSTALAC
AO
115
Usando o fdisk, parti ione o dis o em uma uni a parti ~ao o upando todo o dis o,
que orrespondera ao dispositivo /dev/hd 1. Usando o mke2fs fa a um lesystem nesta
parti ~ao e monte-a no diretorio /sft do front-end. Coloque uma entrada orrespondente
a esta montagem no arquivo /et /fstab. Crie dentro deste diretorio os sub-diretorios
bin/ e log/. Pegue atraves do apêndi e C os s ripts
mirror-kernel
mirror-debian
mirror-debian-non-US
mirror-debian-se urity
e oloque-os no diretorio bin/. Eles devem perten er a root e ser exe utaveis apenas
por root. Pegue tambem, atraves do apêndi e C, os arquivos
mirror-kernel. rontab
mirror-debian. rontab
mirror-debian-non-US. rontab
mirror-debian-se urity. rontab
e use os exemplos que eles ontêm para olo ar entradas no rontab de root do front-end
para rodar estes espelhos. Para editar o rontab de root a erte a variavel de environment
EDITOR para usar o seu editor preferido e use em seguida o omando rontab -e.
Estes exemplos est~ao ongurados para rodar os espelhos diretamente dos sites originais todo dia as 0:00 horas. Isto pode ser frequente demais, es olha os horarios e
intervalos a vontade. Tambem e possvel fazer o espelhamento a partir do servidor do
projeto LinORG em vez de diretamente dos sites originais. Com as melhorias que tem
a onte ido re entemente nas infra-estrutura de rede do pas, em qualquer aso o seu
espelho deve en her rapidamente, provavelmente ja na primeira noite em que rodar.
Assim que a abar de instalar o dis o, vo ê pode en her o espelho de imediato simplesmente rodando os s ripts a m~ao, de preferên ia no ba kground. Esta e tambem uma
boa forma de testar o fun ionamento do sistema. Os s ripts usam o omando wget para
puxar o software, de forma que ele pre isa estar instalado no front-end. Se vo ê estiver
disposto a ler as paginas de manual no wget e, talvez, mexer um pou o nos s ripts, pode
rodar o wget ompletamente a m~ao, interativamente, om logs extensos e ontnuos, que
lhe dar~ao uma boa ideia de qu~ao bem o sistema todo esta fun ionando.
Os espelhos da Debian ser~ao riados automati amente dentro dos diretorios orrespondentes debian, debian-non-US e debian-se urity, mas o do kernel sera riado
dentro do diretorio pub/linux/kernel. Para fa ilitar o a esso, fa a um soft link hamado kernel, apontando para este diretorio dentro de /sft:
kernel -> pub/linux/kernel
116
^
APENDICE
D. RECEITAS
N~ao se esque a de exportar o diretorio /sft do front-end atraves de NFS para todas
as maquinas do PMC, bem omo para quaisquer outras maquinas de sua institui ~ao que
venham a fazer uso dele. Para exportar por NFS basta a res entar mais uma entrada
ao arquivo /et /exports do front-end e rodar o s ript /et /init.d/nfs-server om
o argumento reload. Tambem e possvel exportar o seu espelho atraves de FTP, ongurando um sistema de FTP anônimo, mas vo ê provavelmente n~ao tera de fazer isto.
Pronto, pode ome ar a usar o espelho!
D.2.2 Roteiro de Compila ~ao do Kernel dos Nos
Na se ~ao 3.4 do texto demos o pro edimento geral de ompila ~ao e instala ~ao do kernel
do Linux. Nesta se ~ao vamos dar um roteiro mais detalhado do pro edimento ompleto
de ompila ~ao e instala ~ao do kernel de um no, que e um pou o diferente do usual.
Vamos in luir tambem a feitura de um oppy de boot para o no virtual.
Vamos assumir que a ompila ~ao esteja sendo feita no servidor de dis o e na area de
ompila ~ao dos nos, ou seja, no diretorio /pm /usr/sr / do servidor. A parte ini ial
do pro esso e exatamente igual ao que esta des rito na se ~ao 3.4: obten ~ao do arquivo
linux-2.2.18.tar.gz
ou do arquivo de alguma outra vers~ao mais re ente, a partir de algum espelho ou do site
do kernel em
http://www.kernel.org
Vo ê pode obter esta vers~ao do kernel usando o link abaixo.

ftp://ftp.kernel.org/pub/linux/kernel/v2.2/linux-2.2.18.tar.gz
Este arquivo sera olo ado no diretorio /pm /usr/sr /, um link ou diretorio hamado
linux que ja exista la sera removido ou renomeado e a arvore de odigo-fonte do novo
kernel sera aberto om o omando
tar -xzvf linux-2.2.18.tar.gz
Em seguida o diretorio linux que e riado sera renomeado para linux-2.2.18 om

a vers~ao adequada registrada no nome e um link hamado linux sera riado om o
omando
ln -s linux-2.2.18 linux
Alem disso o \ownership" do diretorio sera mudado re ursivamente para root, om o

omando
~ DE SOFTWARE
AO
117
hown -R root:sr linux-2.2.18
Isto feito entra-se no diretorio linux e ongura-se o kernel om o omando

make x onfig
No sistema de janelas om menus que apare e se lê o arquivo de ongura ~ao do kernel
obtido a partir da se ~ao C.3 ou se faz as modi a ~oes ne essarias baseadas no que se vê
nas guras da se ~ao E.6. Em seguida se salva a nova ongura ~ao, alem de guarda-la em
um arquivo om o nome bem do umentado. Isto feito, ompila-se o kernel e os modulos,
ainda sem instalar nada, usando a sequên ia de omandos
make dep
make zImage
make modules
As diferen as de pro edimento apare em na hora de se instalar o novo kernel de tal

forma que os nos possam boota-lo pela rede. Cuidado! N~ao tente instalar o kernel
e os modulos da forma usual pois om isto vo ê podera estar queimando os

arquivos do proprio servidor! Para ome ar, em vez de instalar o kernel no diretorio
de ada no, vamos olo a-lo em um diretorio /pm /boot-floppy/ que vo ê ja
deve ter riado antes. Este diretorio tambem sera usado para a ria ~ao de um oppy
de boot para o no virtual n0000. Copie o kernel e a tabela de smbolos neste diretorio
usando os omandos
/boot/
p -p System.map /pm /boot-floppy/System.map-2.2.18

p -p ar h/i386/boot/zImage /pm /boot-floppy/vmlinuz-2.2.18
enquanto vo ê ainda esta em /pm /usr/sr /linux/. Caso ja exista la uma vers~ao anterior do mesmo kernel, antes de fazer isto mude os nomes dos arquivos orrespondentes,
por exemplo a res entando a eles uma termina ~ao .OLD. Para terminar a instala ~ao do
novo kernel, basta ir para o diretorio /pm / e rodar la o s ript
make-netboot-kernel
ou o s ript
make-netboot-kernels
dependendo da losoa de boot remoto que estiver usando, om um uni o kernel ou

om um kernel para ada no. Seja qual for o aso, estes s ripts v~ao utilizar o programa
mknbi para fazer, a partir do kernel que vo ê olo ou em /pm /boot-floppy/, um ou
mais kernels bootaveis pela rede, que ser~ao olo ados no diretorio /pm /tftpboot/. E
laro que vo ê pre isa ter o programa mknbi instalado no servidor. Para que o daemon
tftpd en ontre o kernel quando algum no o soli itar ao servidor pela rede, ertique-se
de que haja um soft link na raiz do servidor apontando para este diretorio:
118
^
APENDICE
D. RECEITAS
lrwxrwxrwx 1 root root 12 <data> /tftpboot -> pm /tftpboot
Alternativamente, vo ê pode modi ar o arquivo /et /inetd. onf e mudar o nome do

diretorio que apare e na linha do servi o tftp, ou a res entar mais este diretorio aquela
linha. Com tudo isto feito, o novo kernel esta pronto para ser transferido pela rede e
bootado pelos nos.
Para instalar os modulos nos nos, vamos ter de realizar algumas opera ~oes preliminares. Cuidado! N~ao tente instalar os modulos da forma usual pois om isto
vo ê podera estar queimando os modulos do proprio servidor! Isto se deve ao
fato de que a estrutura de make da arvore de ompila ~ao do kernel esta programada
para olo ar os modulos no diretorio /lib/modules/2.2.18/, onde est~ao os modulos
do servidor, n~ao nos diretorios /pm /0000/lib/modules/2.2.18/, et , onde eles têm
de ser olo ados para que possam ser usados pelos nos. Para ontornar este problema,
ome e mudando o nome do diretorio dos modulos, se ele ja existe no servidor:
mv /lib/modules/2.2.18 /lib/modules/2.2.18.CURRENT
Tendo feito isto, vo ê agora pode instalar os modulos da forma usual, om o omando
make modules_install
exe utado na raiz da arvore do kernel que vo ê esta ompilando. Vamos agora transferir
estes modulos par ao no virtual n0000, usando para isto uma pipeline de omandos tar,
tar -C /lib/modules - pf - 2.2.18 | tar -C /pm /0000/lib/modules -xpvf -
Tendo feito isto, podemos agora remover o diretorio em /lib/modules/,

\rm -fr /lib/modules/2.2.18/
e voltar o diretorio original para o seu lugar orreto,

mv /lib/modules/2.2.18.CURRENT /lib/modules/2.2.18
Agora so falta distribuir os modulos para todos os nos, a partir do no virtual n0000.
Vo ê pode fazer isto om uma sequên ia de pipelines de tar. Va para o diretorio /pm
e exe ute linhas tais omo

tar -C 0000/lib/modules - pf - 2.2.18 | tar -C 0001/lib/modules -xpvf -
para ada no que de fato existir. Se vo ê tem muitos nos, pode ser uma boa ideia
es rever um pequeno s ript para fazer isto automati amente. Para terminar, n~ao se
esque a de rodar, neste mesmo diretorio, o s ript
~ DE SOFTWARE
AO
119
hard-link- ommon-files-root
que vai diminuir a o upa ~ao de dis o do lesystem /pm . Pronto, o seu novo kernel e os
modulos orrespondentes est~ao prontos para uso.
Uma ultima oisa que podemos fazer e gerar um oppy bootavel a partir do diretorio
/pm /boot-floppy/, om o qual vo ê podera bootar o seu terminal om a montagem
da raiz pela rede via NFS-root, no papel do no virtual n0000. Para fazer isto uma serie
de outros arquivos pre isam estar em /pm /boot-floppy/, a lista ompleta e
lrwxrwxrwx
-rw-r--r--rw-r--r--rw-r--r--rw-r--r-lrwxrwxrwx
-rw-r--r--rw-r--r--rw-r--r--rw------lrwxrwxrwx
-rw-r--r--
1
1
1
1
1
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
17
158801
512
512
4568
15
454
268
260
4608
14
443933
<data>
<data>
<data>
<data>
<data>
<data>
<data>
<data>
<data>
<data>
<data>
<data>
System.map -> System.map-2.2.18

System.map-2.2.18
boot.0200
boot.0300
boot.b
lilo. onf -> lilo. onf-TTYS0
lilo. onf-TTYS0
lilo. onf-VGA
lilo.msg
map
vmlinuz -> vmlinuz-2.2.18
vmlinuz-2.2.18
Alem do kernel e do mapa de smbolos, têm de estar la opias dos boot blo ks apropriados e os arquivos do lilo. Vo ê pode obter um arquivo tar omprimido ontendo
todos estes arquivos a partir da se ~ao C.3, mas uidado ao abrir este tar para n~ao
sobre-es rever os kernel e o mapa de smbolos que vo ê a abou de olo ar no diretorio
/pm /boot-floppy/! Vo ê deve fazer isto antes de ompilar o novo kernel ou ent~ao deve
retirar do tar e olo ar no diretorio apenas os outros arquivos. Vo ê sempre pode abrir
o tar dentro de um diretorio temporario e mover os arquivos apropriados a m~ao.
Observe que existem dois arquivos de ongura ~ao diferentes para o lilo, um hamado lilo. onf-TTYS0 e outro hamado lilo. onf-VGA. O primeiro serve para o aso
de vo ê querer que o no virtual n0000 utilize omo onsole a primeira porta serial, o
segundo para o aso de vo ê querer usar o monitor e te lado do mi ro omo onsole.
Como vo ê estara usando o terminal no papel de no virtual, e provavel que esta segunda
alternativa seja a mais apropriada. Neste aso, mude o soft link lilo. onf para apontar
para o arquivo adequado.
Uma vez que o seu diretorio /pm /boot-floppy/ esteja ompleto e orreto, vo ê
deve opiar todos os seus onteudos em um disquete. Para isto obtenha um disquete de
1.4 MB em boas ondi ~oes, oloque-o no primeiro drive do servidor e formate-o om um
lesystem ext2 usando o omando
mke2fs /dev/fd0
120
^
APENDICE
D. RECEITAS
Em seguida monte o oppy no diretorio /floppy/ext2/ do servidor om o omando

mount /floppy/ext2/
Uma ver montado o oppy, transra para eles todos os arquivos que est~ao no diretorio
/pm /boot-floppy/ usando uma pipeline de tar,
tar -C /pm /boot-floppy - pf - . | tar -C /floppy/ext2/ -xpvf -
Por ultimo, para tornar o oppy bootavel va para o diretorio /floppy/ext2/ e exe ute
o omando lilo da forma
lilo -C lilo. onf
Pronto, vo ê pode sair do diretorio /floppy/ext2/, desmontar o oppy, retira-lo do

drive e mar a-lo om um label dizendo que trata-se do oppy de boot do no n0000.
Cuidado! Nun a retire um oppy do drive antes de desmonta-lo do sistema!
Alem disso, espere a luz de atividade do drive se apagar para retirar o oppy. Vo ê pode
querer fazer uma opia binaria do onteudo deste oppy, assim, aso ele seja dani ado,
o que e omum a onte er om oppies deste tipo, sera fa il fazer um novo. Para fazer
a opia binaria oloque o oppy de novo no drive e use o omando dd,
dd if=/dev/fd0 of=boot-floppy-2.2.18.dd
Note que n~ao e ne essario montar o oppy para fazer isto. Guarde a opia, que tera
exatamente 1474560 bytes, no diretorio pm . Vo ê pode obter uma imagem binaria
omo esta, omprimida om o omando gzip, atraves da se ~ao C.3. Para fazer um
oppy novo, basta olo ar um oppy no drive e reverter a opera ~ao a ima,
dd if=boot-floppy-2.2.18.dd of=/dev/fd0
D.2.3 Roteiro de Compila ~ao do Etherboot
O sistema Etherboot sera usado para duas nalidades: para ompilar as imagens rom que
ser~ao posteriormente gravadas nos hips de boot e para ompilar e instalar o programa
mknbi que e usado para transformar um kernel usual do Linux em um kernel bootavel
pela rede. O esquema de ompila ~ao e instala ~ao e muito simples. Obtenha o arquivo
tar om o odigo fonte a partir da home page do projeto em
http://etherboot.sour eforge.net/
O arquivo tera nome etherboot-<vers>.tar.gz, in luindo a vers~ao. Vo ê deve ir para

o diretorio /usr/sr / do servidor e abrir este arquivo om o omando
~ DE SOFTWARE
AO
121
tar -xzvf etherboot-<vers>.tar.gz
Sera riado um sub-diretorio etherboot-<vers> ontendo as fontes.

Para ompilar as imagens rom, entre no diretorio etherboot-<vers>/sr / e exe ute
o omando make. As imagens ser~ao todas ompiladas e poder~ao ser en ontradas no subdiretorio etherboot-<vers>/sr /bin32/, om nomes tais omo 3 905b-tpo100.rom
e 3 905b-tpo100.lzrom, que s~ao as imagens relevantes para a pla a de rede 3C905B
que re omendamos aqui. As imagens om termina ~ao .lzrom s~ao omprimidas e têm
16 KB, enquanto as n~ao- omprimidas têm 32 KB. Qualquer delas serve, desde que aiba
no seu hip de eprom ou eeprom.
Interessantemente, vo ê pode ompilar e puxar estes roms on-line na WWW, usando
um formulario que se en ontra no site
http://rom-o-mati .net/
Entretanto, isto n~ao sera util no aso de vo ê ter de ompilar uma imagem espe ial.
Por exemplo, para ompilar o rom espe ial om o bug-x para algumas pla as 3C905B
om hipset feito pela Lu ent, omo esta expli ado na se ~ao A.2, vo ê tera de editar
o arquivo etherboot-<vers>/sr /Makefile. Para ompilar roms que usem o onsole serial, in lusive es olhendo a velo idade da porta, vo ê tera de editar o arquivo
etherboot-<vers>/sr /Config. Se quiser, vo ê pode obter os roms ja ompilados para
a pla a 3C905B e uma imagem binaria do oppy de boot atraves da se ~ao C.3.
Para ompilar e instalar o programa mknbi vo ê deve entrar no sub-diretorio
etherboot-<vers>/mknbi-<vers>
e usar o omando make seguido de um

make install
Ser~ao olo ados varios arquivos no diretorio /usr/lo al/, distribudos pelos sub-diretorios
e man/man1/. Certique-se de que o diretorio /usr/lo al/bin/ esta
in ludo no path do usuarios root e que o diretorio /usr/lo al/man/ esta in ludo no
arquivo /et /manpath. onfig que ongura o omando man. este ultimo e default na
Debian. Se vo ê quiser que os arquivos sejam instalados em outros lugares, vo ê tera
de editar e modi ar o arquivo
bin/, lib/mknbi/
etherboot-<vers>/mknbi-<vers>/Makefile
Algumas vers~oes do programa mknbi têm um bug em uma parte do programa que
n~ao nos interessa mas que impede o programa de rodar. Se isto a onte er, edite diretamente o programa, que e um s ript es rito em perl, o qual podera ser en ontrado em
/usr/lo al/lib/mknbi/mknbi, simplesmente a hando e omentando a linha que segue:
122
^
APENDICE
D. RECEITAS
#use Trun FD;
Com isto feito, o seu programa mknbi esta pronto para uso. Se quiser vo ê pode obter
a vers~ao 1.0 do mknbi om tudo ja ompilado atraves da se ~ao C.3.
Uma alternativa interessante para o uso das pla as 3C905B e 3C905C e o uso de boot
proms espe iais hamados de \ ash-eprom". Trata-se de hips que, assim omo muitos hips de bios das motherboards modernas, podem ser apagados de re-programados
atraves de software que roda dentro do sistema opera ional, om o hip olo ado na
pla a de rede e esta montada normalmente no sistema. Observe que isto evitaria a
ne essidade da aquisi ~ao de um gravador de eprom. Existe suporte no Etherboot para
este tipo de hip nas pla as 3C905B e 3C905C. Ele pode ser en ontrado no sub-diretorio
etherboot-<vers>/ ontrib/3 90xutil/
da arvore de ompila ~ao do Etherboot, onde vo ê podera ompilar as utilidades romutil

(para a pla a 3C905), bromutil (para a pla a 3C905B) e romutil (para a pla a
3C905C), as quais rodam no Linux. Entretanto, omo n~ao dispomos deste tipo de
hip de boot, ainda n~ao pudemos testar estas utilidades. Claramente, esta alernativa e
a mais onveniente do ponto de vista da opera ~ao do sistema, permitindo a mudan a
dos programas de boot sem sequer se desligar e, muito menos, se desmontar os nos. Os
hips de ash-eprom que s~ao a eitos por estas pla as s~ao produzidos pela Atmel, ujo
endere o e
http://www.atmel. om
Atraves desta pagina des obre-se que o representante no Brasil e a Haste , que a
aqui em S~ao Paulo, fone (55) (11) 5641-2177. Quando a pro uramos, esta rma infelizmente n~ao tinha os hips para pronta entrega. Os hips devem ter en apsulamento
tipo \DIP". As pla as 3C905 a eitam o hip AT27C512, de 64 KB, as pla as 3C905B
os hips AT27C512 (64 KB) e AT27C010 (128 KB), enquanto a pla a 3C905C a eita o
hip AT49BV512, de 64 KB, que fun iona om voltagem mais baixa. Observe que ha
um hip de 128 KB hamado AT27C1024 que n~ao e a eito por estas pla as. Os hips de
64 KB ustam em torno de R$ 4.00 ada um, os de 128 KB er a de R$ 8.00 ada um.
Em suma, o problema n~ao e o pre o, e a obten ~ao destes hips no mer ado na ional.
D.3 Re eitas de Opera ~ao

D.3.1 Como usar o onsole serial
O onsole serial e uma forma de vo ê poder a ompanhar e ontrolar o boot de um no
atraves de um terminal ligado a uma porta serial do motherboard do no. O terminal
~
D.3. RECEITAS DE OPERAC
AO
123
tambem podera ser usado para fazer logins no no, mesmo se ele estiver em modo singleuser. Isto e util quando a onte er qualquer problema om um no, uma vez que ele n~ao
disp~oe do monitor VGA usual.
O terminal pode ser um terminal ASCII tradi ional ligado a porta atraves de um
abo serial ruzado, omo um VT100, VT200 ou similar, mas na realidade n~ao vai ser
ne essario vo ê adquirir um tal terminal, pois e possvel usar uma janela X11 em alguma
outra maquina omo um terminal ASCII. Em outras palavras, vamos estar emulando
um terminal serial atraves de software e usar uma janela no terminal do PMC omo
onsole serial de um no qualquer. Vo ê tera apenas de adquirir ou fazer um abo serial
ruzado om omprimento su ientemente para poder ser ligado ao terminal do PMC e
a qualquer um dos nos.
Tanto o kernel do Linux quanto o rom de boot podem ser ompilados om suporte
para o onsole serial. Pode-se es olher a velo idade de tro a de dados, bem omo as ara tersti as da porta. O default e 9600 baud, no-parity, 8 bits, (9600n8), mas e possvel
usar velo idades de ate 38400 baud (38400n8), o que re omendamos. O programa do
rom usa de forma automati a o onsole serial se ele tiver sido ompilado om o suporte
para ele. Ja no aso do kernel e ne essario passar um parâmetro de linha de omando
durante o boot, o qual tem a forma onsole=ttyS0,9600 ou onsole=ttyS0,38400,
onforme for o aso.
Tanto o boot blo k do kernel bootavel pela rede quanto o daemon dh pd quanto o
lilo, que sera usado no oppy de boot, podem passar para o kernel o parâmetro de linha
de omando que ativa o uso do onsole serial. Alem disso, o proprio lilo tambem tem
uma op ~ao para fun ionar atraves do onsole serial, que tem a forma serial=0,9600n8
ou serial=0,38400n8, onforme for o aso. Para terminar, o sistema dos nos pode ser
ongurado para ini iar um programa getty em ada porta serial, de forma a permitir
logins atraves delas, exatamente omo em qualquer outro terminal.
Para poder usar o onsole serial desta forma vo ê pre isa ter os seguintes elementos
em seus devidos lugares:
As portas seriais da motherboard do no devem estar habilitadas no setup do bios.

O eprom na pla a de rede do no deve onter um rom ompilado om suporte para
o onsole serial.
O kernel do Linux bootavel pela rede deve ter sido ompilado om suporte para o
onsole serial.
A op ~ao de onsole serial deve estar en odi ada no boot blo k do kernel ou sendo
passada pelo daemon dh pd.
Para boot pelo oppy, o lilo deve estar om a op ~ao de onsole serial e deve passar
o parâmetro para o kernel.
124
^
APENDICE
D. RECEITAS
Deve haver um abo serial ruzado de omprimento su iente e om os one tores
adequados em ada ponta.

As portas seriais da motherboard do terminal do PMV devem estar ativadas no
setup do bios.
O programa seyon deve estar instalado no terminal do PMC, atraves da simples
abertura de um pa ote Debian.
O usuario deve ter as ongura ~oes adequadas para o seyon em seu arquivo
.Xresour es.
Com tudo isto satisfeito, o pro edimento e simples: basta ligar o abo serial a primeira porta do no e a primeira porta do terminal e rodar o programa seyon. Apare era
uma janela de xterm, que e o emulador de terminal usado pelo seyon, dê [Enter e
ome e a usar o terminal. E onveniente usar o seyon om alguns parâmetros, tais
omo
seyon -- -rv -fn 10x20
Os parâmetros que apare em depois do -- ser~ao passados para o xterm. Vo ê pode

denir um alias para o seyon ontendo estas op ~oes. As entradas relativas ao programa
seyon para o arquivo .Xresour es de ongura ~ao de re ursos do X11 que o usuario
deve ter em sua onta podem ser obtidas atraves da se ~ao C.1.5.
Atraves da se ~ao E.2 pode-se ver duas imagens de janelas do xterm sendo usadas
om o seyon, numa omo um terminal para login, em outra omo o onsole de boot.
Apêndi e E
Imagens
Apresentamos neste apêndi e imagens, em geral s reen shots, que ontêm informa ~oes
relevantes sobre a montagem e opera ~ao de um PMC. Como a informa ~ao esta em formato gra o, envolvendo arquivos muito grandes, este apêndi e n~ao ontem as imagens,
mas apenas as referên ias aos hyperlinks apropriados da WWW.
Todos os arquivos om as imagens est~ao disponveis na rede nas URLs indi adas. Caso vo ê esteja lendo isto em papel e queira poupar tempo na digita ~ao de URLs, lembre-se
de que existe uma vers~ao em HTML deste do umento, no qual todos os links s~ao ativos,
levando diretamente as imagens. Fa a uma opia desta vers~ao em sua maquina ou a esse
om o browser a vers~ao que e mantida na home page do PMC, no endere o:
http://latt.if.usp.br/pm /Howto/
Assim, sup~oem-se que vo ê use um browser da WWW para ver todas as imagens
atraves da Internet. Observe que, para poder a essar a Internet om um browser rodando
no terminal dentro da rede privada de um PMC, basta rodar o browser no front-end,
om a janela dire ionada para o display X11 do terminal.
E.1 Parti ionamento dos Dis os

Mostramos aqui s reen-shots de um terminal rodando o programa fdisk que pode ser
usado para parti ionar os dis os. E este o programa de parti ionamento usado pelo
programa de instala ~ao da Debian. O parti ionamento mostrado em ada aso e aquele
que re omendamos para ada um dos omponentes do PMC.
Primeiro dis o IDE do front-end: sistema lo al:
/pm /imagens/disks/fend-hda.jpg
Primeiro dis o SCSI do servidor: sistema lo al:

/pm /imagens/disks/serv-sda.jpg
125
126
^
APENDICE
E. IMAGENS
Segundo dis o SCSI do servidor: sistema dos nos:

/pm /imagens/disks/serv-sdb.jpg
Primeiro dis o IDE do terminal: sistema lo al:

/pm /imagens/disks/term-hda.jpg
E.2 Uso do Console Serial dos Nos

Mostramos nas imagem abaixo o programa seyon sendo usado omo um terminal para o
onsole serial de um no de um PMC. O terminal usado pelo seyon e o programa xterm,
que pode estar rodando em qualquer sistema om uma porta serial que esteja one tada
a porta serial do no atraves de um abo serial ruzado. A janela deve estar no terminal,
que e a uni a maquina dentro da rede privada do PMC que roda o X11.
Uso omo terminal: Alem da janela do terminal xterm, onde se vê, em uma sess~ao
de shell, os lesystems de sistema do no, podemos ver a janela de ontrole do

programa seyon.
/pm /imagens/seyon-term.jpg
Uso para o boot: Vê-se na janela do terminal o no prestes a bootar pela rede. As
ultimas linhas que apare em s~ao o prompt do programa de boot que esta gravado
na eprom ou eeprom da pla a de rede.
/pm /imagens/seyon-boot.jpg
E.3 Congura ~ao do Kernel do Front-End

Mostramos aqui os 14 menus de ongura ~ao do kernel do Linux, para o aso do kernel
do front-end. Dos 43 menus que apare em 29 n~ao s~ao usados de todo. No aso destes
menus indi amos abaixo que n~ao ha nenhuma sele ~ao a ser feita neles, ou seja, todos os
tens destes menus devem estar desativados ou om a op ~ao \n" (de \no") sele ionada.
Como alguns menus s~ao muito longos, so s~ao mostradas as partes dos menus nas quais
alguma sele ~ao deve ser feita.
Linux kernel onguration (menu prin ipal): n~ao ha sele ~oes a fazer neste menu,
que simplesmente hama os outros.
/pm /imagens/fend/00-Linux-kernel- onfiguration.jpg
Code maturity level options: nenhuma sele ~ao.

/pm /imagens/fend/01- ode-maturity-level-options.jpg
~ DO KERNEL DO FRONT-END
E.3. CONFIGURAC
AO
Pro essor type and features:

/pm /imagens/fend/02-pro essor-type-and-features.jpg
Loadable module support:

/pm /imagens/fend/03-loadable-module-support.jpg
General setup:
/pm /imagens/fend/04-general-setup.jpg
Plug and play support: nenhuma sele ~ao.

/pm /imagens/fend/05-plug-and-play-support.jpg
Blo k devi es:

/pm /imagens/fend/06-blo k-devi es-1.jpg
/pm /imagens/fend/06-blo k-devi es-2.jpg
Networking options:
/pm /imagens/fend/07-networking-options-1.jpg
/pm /imagens/fend/07-networking-options-2.jpg
QoS and/or fair queueing: nenhuma sele ~ao.

/pm /imagens/fend/08-qos-and-or-fair-queueing.jpg
Telephony support: nenhuma sele ~ao.

/pm /imagens/fend/09-telephony-support.jpg
SCSI support: nenhuma sele ~ao.

/pm /imagens/fend/10-s si-support.jpg
SCSI low-level drivers: nenhuma sele ~ao.

/pm /imagens/fend/11-s si-low-level-drivers.jpg
I2O devi e support: nenhuma sele ~ao.

/pm /imagens/fend/12-i2o-devi e-support.jpg
Network devi e support:

/pm /imagens/fend/13-network-devi e-support.jpg
Ar net devi es: nenhuma sele ~ao.

/pm /imagens/fend/14-ar net-devi es.jpg
127
128
^
APENDICE
E. IMAGENS
Ethernet (10 or 100 Mbit):

/pm /imagens/fend/15-ethernet-10-or-100-Mbit.jpg
Ethernet 1000 Mbit: nenhuma sele ~ao.

/pm /imagens/fend/16-ethernet-1000-Mbit.jpg
Appletalk devi es: nenhuma sele ~ao.

/pm /imagens/fend/17-appletalk-devi es.jpg
Token ring devi es: nenhuma sele ~ao.

/pm /imagens/fend/18-token-ring-devi es.jpg
WAN interfa es: nenhuma sele ~ao.

/pm /imagens/fend/19-wan-interfa es.jpg
Amateur radio support: nenhuma sele ~ao.

/pm /imagens/fend/20-amateur-radio-support.jpg
IRDA (infrared) support: nenhuma sele ~ao.

/pm /imagens/fend/21-irda-infrared-support.jpg
Infrared port devi e drivers: nenhuma sele ~ao.

/pm /imagens/fend/22-infrared-port-devi e-drivers.jpg
ISDN subsystem: nenhuma sele ~ao.

/pm /imagens/fend/23-isdn-subsystem.jpg
ISDN feature submodules: nenhuma sele ~ao.

/pm /imagens/fend/24-isdn-feature-submodules.jpg
Passive ISDN ards: nenhuma sele ~ao.

/pm /imagens/fend/25-passive-isdn- ards.jpg
A tive ISDN ards: nenhuma sele ~ao.

/pm /imagens/fend/26-a tive-isdn- ards.jpg
Old CDROM drivers (not s si, not ide): nenhuma sele ~ao.
/pm /imagens/fend/27-old- drom-drivers-not-s si-not-ide.jpg
Chara ter devi es:

/pm /imagens/fend/28- hara ter-devi es-1.jpg
/pm /imagens/fend/28- hara ter-devi es-2.jpg
~ DO KERNEL DO FRONT-END
E.3. CONFIGURAC
AO
Mi e:
/pm /imagens/fend/29-mi e.jpg
Joysti ks: nenhuma sele ~ao.

/pm /imagens/fend/30-joysti ks.jpg
Wat hdog ards: nenhuma sele ~ao.

/pm /imagens/fend/31-wat hdog- ards.jpg
Video for linux: nenhuma sele ~ao.

/pm /imagens/fend/32-video-for-linux.jpg
Ftape, the oppy tape driver: nenhuma sele ~ao.

/pm /imagens/fend/33-ftape-the-floppy-tape-driver.jpg
USB support: nenhuma sele ~ao.

/pm /imagens/fend/34-usb-support.jpg
Filesystems:
/pm /imagens/fend/35-filesystems-1.jpg
/pm /imagens/fend/35-filesystems-2.jpg
Network le systems:
/pm /imagens/fend/36-network-file-systems.jpg
Partition types: nenhuma sele ~ao.

/pm /imagens/fend/37-partition-types.jpg
Native language support:

/pm /imagens/fend/38-native-language-support-1.jpg
/pm /imagens/fend/38-native-language-support-2.jpg
Console drivers:
/pm /imagens/fend/39- onsole-drivers.jpg
Sound: nenhuma sele ~ao.

/pm /imagens/fend/40-sound.jpg
Additional low-level sound drivers: nenhuma sele ~ao.

/pm /imagens/fend/41-additional-low-level-sound-drivers.jpg
Kernel ha king: nenhuma sele ~ao.

/pm /imagens/fend/42-kernel-ha king.jpg
129
130
^
APENDICE
E. IMAGENS
E.4 Congura ~ao do Kernel do Servidor

do servidor. Dos 43 menus que apare em 27 n~ao s~ao usados de todo. No aso destes
/pm /imagens/serv/00-Linux-kernel- onfiguration.jpg

/pm /imagens/serv/01- ode-maturity-level-options.jpg

/pm /imagens/serv/02-pro essor-type-and-features.jpg

/pm /imagens/serv/03-loadable-module-support.jpg
General setup:
/pm /imagens/serv/04-general-setup.jpg

/pm /imagens/serv/05-plug-and-play-support.jpg
Blo k devi es:

/pm /imagens/serv/06-blo k-devi es-1.jpg
/pm /imagens/serv/06-blo k-devi es-2.jpg
Networking options:
/pm /imagens/serv/07-networking-options-1.jpg
/pm /imagens/serv/07-networking-options-2.jpg

/pm /imagens/serv/08-qos-and-or-fair-queueing.jpg

/pm /imagens/serv/09-telephony-support.jpg
~ DO KERNEL DO SERVIDOR
E.4. CONFIGURAC
AO
SCSI support:
/pm /imagens/serv/10-s si-support.jpg
SCSI low-level drivers:

/pm /imagens/serv/11-s si-low-level-drivers-1.jpg
/pm /imagens/serv/11-s si-low-level-drivers-2.jpg

/pm /imagens/serv/12-i2o-devi e-support.jpg

/pm /imagens/serv/13-network-devi e-support.jpg

/pm /imagens/serv/14-ar net-devi es.jpg

/pm /imagens/serv/15-ethernet-10-or-100-Mbit.jpg

/pm /imagens/serv/16-ethernet-1000-Mbit.jpg

/pm /imagens/serv/17-appletalk-devi es.jpg

/pm /imagens/serv/18-token-ring-devi es.jpg

/pm /imagens/serv/19-wan-interfa es.jpg

/pm /imagens/serv/20-amateur-radio-support.jpg

/pm /imagens/serv/21-irda-infrared-support.jpg

/pm /imagens/serv/22-infrared-port-devi e-drivers.jpg
131
132
^
APENDICE
E. IMAGENS

/pm /imagens/serv/23-isdn-subsystem.jpg

/pm /imagens/serv/24-isdn-feature-submodules.jpg

/pm /imagens/serv/25-passive-isdn- ards.jpg

/pm /imagens/serv/26-a tive-isdn- ards.jpg
/pm /imagens/serv/27-old- drom-drivers-not-s si-not-ide.jpg
Chara ter devi es:

/pm /imagens/serv/28- hara ter-devi es-1.jpg
/pm /imagens/serv/28- hara ter-devi es-2.jpg
Mi e:
/pm /imagens/serv/29-mi e.jpg

/pm /imagens/serv/30-joysti ks.jpg

/pm /imagens/serv/31-wat hdog- ards.jpg

/pm /imagens/serv/32-video-for-linux.jpg

/pm /imagens/serv/33-ftape-the-floppy-tape-driver.jpg

/pm /imagens/serv/34-usb-support.jpg
Filesystems:
/pm /imagens/serv/35-filesystems-1.jpg
/pm /imagens/serv/35-filesystems-2.jpg
~ DO KERNEL DO TERMINAL
E.5. CONFIGURAC
AO
133
Network le systems:
/pm /imagens/serv/36-network-file-systems.jpg

/pm /imagens/serv/37-partition-types.jpg

/pm /imagens/serv/38-native-language-support-1.jpg
/pm /imagens/serv/38-native-language-support-2.jpg
Console drivers:
/pm /imagens/serv/39- onsole-drivers.jpg

/pm /imagens/serv/40-sound.jpg

/pm /imagens/serv/41-additional-low-level-sound-drivers.jpg

/pm /imagens/serv/42-kernel-ha king.jpg
E.5 Congura ~ao do Kernel do Terminal

do terminal. Dos 43 menus que apare em 29 n~ao s~ao usados de todo. No aso destes
/pm /imagens/term/00-Linux-kernel- onfiguration.jpg

/pm /imagens/term/01- ode-maturity-level-options.jpg

/pm /imagens/term/02-pro essor-type-and-features.jpg
134
^
APENDICE
E. IMAGENS

/pm /imagens/term/03-loadable-module-support.jpg
General setup:
/pm /imagens/term/04-general-setup.jpg

/pm /imagens/term/05-plug-and-play-support.jpg
Blo k devi es:

/pm /imagens/term/06-blo k-devi es-1.jpg
/pm /imagens/term/06-blo k-devi es-2.jpg
Networking options:
/pm /imagens/term/07-networking-options-1.jpg
/pm /imagens/term/07-networking-options-2.jpg

/pm /imagens/term/08-qos-and-or-fair-queueing.jpg

/pm /imagens/term/09-telephony-support.jpg

/pm /imagens/term/10-s si-support.jpg

/pm /imagens/term/11-s si-low-level-drivers.jpg

/pm /imagens/term/12-i2o-devi e-support.jpg

/pm /imagens/term/13-network-devi e-support.jpg

/pm /imagens/term/14-ar net-devi es.jpg

/pm /imagens/term/15-ethernet-10-or-100-Mbit.jpg
~ DO KERNEL DO TERMINAL
E.5. CONFIGURAC
AO

/pm /imagens/term/16-ethernet-1000-Mbit.jpg

/pm /imagens/term/17-appletalk-devi es.jpg

/pm /imagens/term/18-token-ring-devi es.jpg

/pm /imagens/term/19-wan-interfa es.jpg

/pm /imagens/term/20-amateur-radio-support.jpg

/pm /imagens/term/21-irda-infrared-support.jpg

/pm /imagens/term/22-infrared-port-devi e-drivers.jpg

/pm /imagens/term/23-isdn-subsystem.jpg

/pm /imagens/term/24-isdn-feature-submodules.jpg

/pm /imagens/term/25-passive-isdn- ards.jpg

/pm /imagens/term/26-a tive-isdn- ards.jpg
/pm /imagens/term/27-old- drom-drivers-not-s si-not-ide.jpg
Chara ter devi es:

/pm /imagens/term/28- hara ter-devi es-1.jpg
/pm /imagens/term/28- hara ter-devi es-2.jpg
135
136
^
APENDICE
E. IMAGENS
Mi e:
/pm /imagens/term/29-mi e.jpg

/pm /imagens/term/30-joysti ks.jpg

/pm /imagens/term/31-wat hdog- ards.jpg

/pm /imagens/term/32-video-for-linux.jpg

/pm /imagens/term/33-ftape-the-floppy-tape-driver.jpg

/pm /imagens/term/34-usb-support.jpg
Filesystems:
/pm /imagens/term/35-filesystems-1.jpg
/pm /imagens/term/35-filesystems-2.jpg
Network le systems:
/pm /imagens/term/36-network-file-systems.jpg

/pm /imagens/term/37-partition-types.jpg

/pm /imagens/term/38-native-language-support-1.jpg
/pm /imagens/term/38-native-language-support-2.jpg
Console drivers:
/pm /imagens/term/39- onsole-drivers.jpg

/pm /imagens/term/40-sound.jpg

/pm /imagens/term/41-additional-low-level-sound-drivers.jpg

/pm /imagens/term/42-kernel-ha king.jpg
~ DO KERNEL DE UM NO

E.6. CONFIGURAC
AO
137
E.6 Congura ~ao do Kernel de um No

de um no de pro essamento. Dos 43 menus que apare em 32 n~ao s~ao usados de todo.
No aso destes menus indi amos abaixo que n~ao ha nenhuma sele ~ao a ser feita neles,
ou seja, todos os tens destes menus devem estar desativados ou om a op ~ao \n" (de
\no") sele ionada. Como alguns menus s~ao muito longos, so s~ao mostradas as partes
dos menus nas quais alguma sele ~ao deve ser feita.
/pm /imagens/node/00-Linux-kernel- onfiguration.jpg

/pm /imagens/node/01- ode-maturity-level-options.jpg

/pm /imagens/node/02-pro essor-type-and-features.jpg

/pm /imagens/node/03-loadable-module-support.jpg
General setup:
/pm /imagens/node/04-general-setup.jpg

/pm /imagens/node/05-plug-and-play-support.jpg
Blo k devi es: nenhuma sele ~ao.

/pm /imagens/node/06-blo k-devi es.jpg
Networking options:
/pm /imagens/node/07-networking-options-1.jpg
/pm /imagens/node/07-networking-options-2.jpg

/pm /imagens/node/08-qos-and-or-fair-queueing.jpg

/pm /imagens/node/09-telephony-support.jpg
138
^
APENDICE
E. IMAGENS

/pm /imagens/node/10-s si-support.jpg

/pm /imagens/node/11-s si-low-level-drivers.jpg

/pm /imagens/node/12-i2o-devi e-support.jpg

/pm /imagens/node/13-network-devi e-support.jpg

/pm /imagens/node/14-ar net-devi es.jpg

/pm /imagens/node/15-ethernet-10-or-100-Mbit.jpg

/pm /imagens/node/16-ethernet-1000-Mbit.jpg

/pm /imagens/node/17-appletalk-devi es.jpg

/pm /imagens/node/18-token-ring-devi es.jpg

/pm /imagens/node/19-wan-interfa es.jpg

/pm /imagens/node/20-amateur-radio-support.jpg

/pm /imagens/node/21-irda-infrared-support.jpg

/pm /imagens/node/22-infrared-port-devi e-drivers.jpg

/pm /imagens/node/23-isdn-subsystem.jpg
~ DO KERNEL DE UM NO

E.6. CONFIGURAC
AO

/pm /imagens/node/24-isdn-feature-submodules.jpg

/pm /imagens/node/25-passive-isdn- ards.jpg

/pm /imagens/node/26-a tive-isdn- ards.jpg
/pm /imagens/node/27-old- drom-drivers-not-s si-not-ide.jpg
Chara ter devi es:

/pm /imagens/node/28- hara ter-devi es-1.jpg
/pm /imagens/node/28- hara ter-devi es-2.jpg
Mi e: nenhuma sele ~ao.

/pm /imagens/node/29-mi e.jpg

/pm /imagens/node/30-joysti ks.jpg

/pm /imagens/node/31-wat hdog- ards.jpg

/pm /imagens/node/32-video-for-linux.jpg

/pm /imagens/node/33-ftape-the-floppy-tape-driver.jpg

/pm /imagens/node/34-usb-support.jpg
Filesystems:
/pm /imagens/node/35-filesystems-1.jpg
/pm /imagens/node/35-filesystems-2.jpg
Network le systems:
/pm /imagens/node/36-network-file-systems.jpg
139
140
^
APENDICE
E. IMAGENS

/pm /imagens/node/37-partition-types.jpg
Native language support: nenhuma sele ~ao.

/pm /imagens/node/38-native-language-support.jpg
Console drivers:
/pm /imagens/node/39- onsole-drivers.jpg

/pm /imagens/node/40-sound.jpg

/pm /imagens/node/41-additional-low-level-sound-drivers.jpg

/pm /imagens/node/42-kernel-ha king.jpg
Apêndi e F
In ompletudes
Damos aqui uma lista de topi os e assuntos que ainda n~ao foram integrados ao do umento. Desta forma, o leitor pode ar sabendo de oisas que ja existem e problemas
que ja foram resolvidos, mesmo que os detalhes ainda n~ao estejam expli ados no orpo
do do umento. Algum dia este aptulo desapare era e o do umento estara ompleto.
Apêndi e E:
refazer imagens do fdisk (n~ao est~ao exatas, fazer ba kground preto).
Se ~ao 5.2.1: Observa ~ao:
sem fator de potên ia, VA, n~ao W.
Se ~ao A.2:
No site ha tambem um driver para a pla a 3CR990.
Se ~ao C.1: O que falta olo ar:
ongs de usuario para t sh;

ongs de usuario para bash;
/et /init.d/ he kroot para os nos (talvez);
/et /init.d/ he kfs para os nos (provavelmente n~ao).
Se ~ao C.2: O que falta es rever:
s ript para distribui ~ao dos modulos pelos nos;

makele para distribui ~ao de ongs de usuarios;
s ripts de apt-get e dpkg multiplos para os nos;
s ript para es rever longos arquivos dh pd. onf.
141
142
^
APENDICE
F. INCOMPLETUDES
Se ~ao C.4: O que falta olo ar:
esquema de abo TP reto;

esquema de abo TP ruzado;
esquema de abo serial ruzado;
esquema de abo de ontrole do no-break Exide.
Se ~ao D.1.2: O que falta es rever:
ongura ~oes da pla a SCSI do servidor;
ongura ~oes de setup do no-break Exide.
Se ~ao D.3: O que falta es rever:
omo usar o gravador de EPROM (fun ~ao do terminal);
omo ongurar uma nova motherboard (fun ~ao do terminal);
omo adi ionar usuarios e os seus homes;
omo fazer ba kup automati o de root e user.
Bem, na verdade e provavel que a lista de in ompletudes tambem esteja in ompleta...
|:-)
Apêndi e G
Glossario
Apresentamos aqui um glossario de termos te ni os e das siglas que fazem do linguajar
te ni o desta area uma t~ao tremenda sopa de letras.
AGP: Advan ed Graphi s Port. Trata-se de um slot marrom na motherboard, que da
a esso a um ontrolador e bus dedi ados ao ontrole de pla as de vdeo.
AMD: Advan ed Mi ro Devi es. E a ompanhia que produz o pro essador K7, tambem
denominado Athlon.
ATX: E um formato padronizado de motherboard, o nome tambem se apli a aos gabinetes e fontes de for a apropriados para este tipo de motherboard. Trata-se de um
su essor do formato tradi ional AT, om fun ~oes adi ionais tais omo o ontrole
da fonte por software.
BIOS: Basi Input/Output System. E um programa residente na motherboard, que
serve para a ongurar e para permitir o boot de um sistema opera ional.
BTU/h: British Thermal Units por hora. E a unidade de energia usada na dis rimina ~ao da apa idade de aparelhos de ondi ionamento de ar.
CD: Compa t Dis . Um dis o de leitura oti a de 5-1/4".
CDROM: Compa t Dis Read-Only Memory. O mesmo que o dis o a ima, o nome
tambem e usado para o dispositivo de leitura.
CPU: Central Pro essing Unit. O pro essador prin ipal de um omputador, que em
geral in lui o o-pro essador de ponto utuante.
DHCP: Dynami Host Conguration Proto ol. Um proto olo para a ongura ~ao
dinâmi a de hosts em uma rede, usado em onjunto om sistemas de boot remoto.
DIMM: Dual Inline Memory Module. E atualmente o tipo mais omum de memoria
para mi ro- omputadores, trata-se de um modulo de 168 vias.
143
144
^

APENDICE
G. GLOSSARIO
DNS: Domain Name Sevi e. Um servi o de resolu ~ao de nomes em endere os numeri os
e vi e-versa, e um dos servi os fundamentais de fun ionamento da Internet.
EPROM: Erasable Permanente Read-Only Memory. Um tipo de memoria que e per-
manente no sentido de que n~ao se pode apaga-la ou es revê-la pelos metodos

digitais usuais, mas que pode ser apagada por uma lâmpada UV espe ial e em
seguida re-es rita por um equipamento espe ializado.
EEPROM: Ele troni ally Erasable Permanente Read-Only Memory. Um tipo de memoria
que e permanente no sentido de que n~ao se pode apaga-la ou es revê-la pelos

metodos digitais usuais, mas que pode ser apagada e re-es rita por um equipamento espe ializado.
FLASH-EPROM: Um tipo de memoria EPROM que pode ser apagada e es rita na
propria pla a de rede, om o sistema em fun ionamento normal.

FTP: File Transfer Proto ol. E o proto olo padr~ao da Internet para a transferên ia de
arquivos.
HTML: Hyper-Text Markup Language. E a linguagem na qual s~ao es ritas da web,
om apa idades de hipertexto, ou seja, de links que levam de um do umento a
outro.
HTTP: Hyper-Text Transport Proto ol. E o proto olo de transporte usado para as
paginas es ritas em HTML. Tambem pode ser usado para a simples transferên ia
de arquivos.
IDE: Integral Drive Ele troni s. Trata-se do tipo mais omum e barato de dis o rgido
para mi ro- omputadores. Tambem existem unidades ZIP de entrada e sada neste
formato, alem de unidades CDROM.
IP: Internet Proto ol. O proto olo basi o da internet, na verdade um nome para um
onjunto de proto olos de transporte de dados.
KNFSD: Kernel Network File-System Daemon. A nova vers~ao do servidor NFS do
Linux, que esta integrado dentro do kernel.

Kernel: E o programa entral do sistema.
LAN: Lo al Area Network. Trata-se da rede lo al a qual est~ao ligadas as maquinas de
uma institui ~ao. A deni ~ao de uma LAN e que quaisquer duas maquinas dentro
dela possam tro ar pa otes diretamente uma om a outra, sem passar por uma
ter eira maquina, ou seja, por um gateway. Institui ~oes grandes em geral têm
mais de uma LAN.
145
LED: Light Emitting Diode. Um diodo que emite luz quando passa orrente eletri a
atraves dele, omumente usado omo luz de aviso e status em omputadores.
LVD: Low-Voltage Dierential. Trata-se do tipo mais re ente de dis o SCSI, fun io-
nando a 160 MB/s; os dis os tambem s~ao onhe idos omo Ultra-160.
MB: Milh~oes de bytes.

Mbps: Milh~oes de bits por segundo, tambem onhe ida omo baud.
M ops: Milh~oes de opera ~oes de ponto utuante por segundo.
MPI: Message Passing Interfa e. Uma bibliote a de rotinas de passagem de mensagens
voltada para a padroniza ~ao e para a portabilidade de programas entre sistemas

diferentes.
NBD: Network Blo k Devi e. Um dispositivo do Linux que exporta um dispositivo de
blo os, tal omo um dis o, atraves da rede. Trata-se de uma exporta ~ao em nvel
baixo, diferente do sistema NFS, que pode ser usada para fazer swap remoto em
sistemas Linux.
NBI: Network Boot Interfa e. E um padr~ao de organiza ~ao para arquivos ontendo um
kernel do Linux e outras informa ~oes, para que eles possam ser enviados atraves
da rede para que maquinas sem dis os possam bootar o kernel.
NFS: Network File-System. Um sistema que permite a exporta ~ao dos sistemas de
arquivos de uma maquina atraves da rede; os sistemas podem ser montados em

uma maquina remota e os usuarios poder~ao utilizar estes sistemas de arquivos
exatamente omo se fossem sistemas de arquivos lo ais na maquina remota.
NIS: Network Information System. Um sistema de distribui ~ao de informa ~oes de sis-
tema para onjuntos de maquinas em uma rede, que s~ao denominados de domnios
NIS.
NTP: Network Time Proto ol. Um proto olo para a sin roniza ~oes dos relogios de
omputadores atraves da rede.
NQS: Network Queueing System. Um sistema de submiss~ao de jobs a servidores de pro-
essamento atraves da rede; os jobs am organizados em las de espera segundo

riterios te ni os e de prioridade.
PA: Pre ision Arithmeti . A mar a da HP para a sua arquitetura de pro essado-
res RISC, que in lui um dos melhores o-pro essadores de ponto utuante em
existên ia.
146
^

APENDICE
G. GLOSSARIO
PCI: Peripheral Componente Inter one t. Um bus de arquitetura bem aberta e pa-
dronizada para a onex~ao de pla as ontroladoras a um sistema; e ara terizado

por slots bran os na motherboard; e normalmente usado para pla as de rede, de
ontrole de dis o e de vdeo, entre outras.
PMC: Poor Man's Cluster, ou Parallel Ma hine Cluster.
PVM: Parallel Virtual Ma hine. Uma bibliote a de rotinas de passagem de mensagens
voltada para a integra ~ao de varios sistemas om arquiteturas e ara tersti as
diferentes em um uni o sistema de pro essamento numeri o.
RAM: Random A ess Memory. A memoria dinâmi a rapida usada em um omputador, ujo onteudo e perdido ao se desligar a maquina.
RDRAM: Rambus Dynami Random A ess Memory. Um tipo de RAM, mais rapido
que o atual, que esta em pro esso de lan amento no mer ado.
ROM: Read-Only Memory. Qualquer tipo de memoria permanente, que se destine
apenas a leitura.
RISC: Redu ed Instru tion Set Computer. Um tipo de arquitetura de pro essador,
om um numero reduzido de instru ~oes exe utadas diretamente pelo proprio pro essador. Num erto momento teve uma grande importân ia no desenvolvimento
de pro essadores muito rapidos, mas hoje e apenas mais uma das arquiteturas
possveis.
SCSI: Small Computer System Interfa e. Um tipo bem aberto e padronizado de bus
para a onex~ao de dis os rgidos e outros dispositivos de armazenamento em massa
de dados, tais omo unidades de ta e unidades CDROM. In lui um o-pro essador
dedi ado as atividades de leitura e es rita dos dados, o que o torna muito mais
rapido e um pou o mais aro do que o sistema IDE.
SDRAM: Syn hronous Dynami Random A ess Memory. Um tipo de RAM, muito
rapido, que e o padr~ao atual para o mer ado de mi ro- omputadores.
TCP: Transmission Control Proto ol. O prin ipal proto olo de transporte de dados da
Internet.
TFTP: Trivial File Transfer Proto ol. Um sistema muito simples de transmiss~ao de
arquivos pela Internet, que n~ao in lui sistemas de autenti a ~ao e e usado apenas
para o boot remoto de sistemas.
TP: Twisted Pair. O padr~ao mais omum hoje para as onex~oes de rede de urta
distân ia, em geral dentro de um mesmo predio, atraves do uso de pares tran ados
de os de obre.
147
UDP: User Datagram Proto ol. Outro proto olo de transporte de dados da Internet,
que e mais rapido e menos onavel por n~ao ter he agem de erros omo parte do
proto olo; a he agem de erros de transmiss~ao a por onta dos apli ativos.
UNFSD: Userspa e Network File-System Daemon. O antigo servidor de NFS do Linux,
que fun iona ompletamente no \userspa e", o que quer dizer que e um daemon
independente, n~ao integrado ao kernel.
UTP: Unshielded Twisted Pair. O nome ompleto dos abos TP.
WWW: World Wide Web. A teia mundial, um espe ie de enorme ban o de dados
multimdia que al an a todo o mundo, om paginas em HTML e outros tipos de
dado sendo transportados pelo proto olo HTTP.
X11: E o sistema gra o de janelas usado no Linux.
ZIP: E o nome de um novo formato de oppy de 100 MB, muito onavel, que esta se
tornando um padr~ao de fato.
Apêndi e H
Li en a
Nesta apêndi e trans revemos a parte legal da vers~ao original da Li en a Publi a Geral
do projeto GNU da Free Software Foundation (General Publi Li ense ou GPL), sob
os termos da qual este do umento e distribudo. O texto ompleto do do umento de
li en a, bem omo uma tradu ~ao dele para o Português, podem ser en ontrados nos
endere os
http://latt.if.usp.br/fma215/apostilas/GPL engl.html
http://latt.if.usp.br/fma215/apostilas/GPL port.html
GNU GENERAL PUBLIC LICENSE

Version 2, June 1991
1989, 1991 Free Software Foundation, In .
Copyright
59 Temple Pla e, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to opy and distribute verbatim opies
of this li ense do ument, but hanging it is not allowed.
Preamble
The li enses for most software are designed to take away your freedom to share and
hange it. By ontrast, the GNU General Publi Li ense is intended to guarantee your
freedom to share and hange free software{to make sure the software is free for all its
users. This General Publi Li ense applies to most of the Free Software Foundation's
software and to any other program whose authors ommit to using it. (Some other Free
Software Foundation software is overed by the GNU Library General Publi Li ense
instead.) You an apply it to your programs, too.
When we speak of free software, we are referring to freedom, not pri e. Our General
Publi Li enses are designed to make sure that you have the freedom to distribute opies
148
149
of free software (and harge for this servi e if you wish), that you re eive sour e ode
or an get it if you want it, that you an hange the software or use pie es of it in new
free programs; and that you know you an do these things.
To prote t your rights, we need to make restri tions that forbid anyone to deny you
these rights or to ask you to surrender the rights. These restri tions translate to ertain
responsibilities for you if you distribute opies of the software, or if you modify it.
For example, if you distribute opies of su h a program, whether gratis or for a fee,
you must give the re ipients all the rights that you have. You must make sure that they,
too, re eive or an get the sour e ode. And you must show them these terms so they
know their rights.
We prote t your rights with two steps: (1) opyright the software, and (2) oer
you this li ense whi h gives you legal permission to opy, distribute and/or modify the
software.
Also, for ea h author's prote tion and ours, we want to make ertain that everyone
understands that there is no warranty for this free software. If the software is modied
by someone else and passed on, we want its re ipients to know that what they have
is not the original, so that any problems introdu ed by others will not re e t on the
original authors' reputations.
Finally, any free program is threatened onstantly by software patents. We wish to
avoid the danger that redistributors of a free program will individually obtain patent
li enses, in ee t making the program proprietary. To prevent this, we have made it
lear that any patent must be li ensed for everyone's free use or not li ensed at all.
The pre ise terms and onditions for opying, distribution and modi ation follow.
GNU GENERAL PUBLIC LICENSE
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND
MODIFICATION
0. This Li ense applies to any program or other work whi h ontains a noti e pla ed
by the opyright holder saying it may be distributed under the terms of this
General Publi Li ense. The \Program", below, refers to any su h program or
work, and a \work based on the Program" means either the Program or any
derivative work under opyright law: that is to say, a work ontaining the Program
or a portion of it, either verbatim or with modi ations and/or translated into
another language. (Hereinafter, translation is in luded without limitation in the
term \modi ation".) Ea h li ensee is addressed as \you".
A tivities other than opying, distribution and modi ation are not overed by
this Li ense; they are outside its s ope. The a t of running the Program is not
restri ted, and the output from the Program is overed only if its ontents onstitute a work based on the Program (independent of having been made by running
the Program). Whether that is true depends on what the Program does.
150
^
APENDICE
H. LICENC
A
1. You may opy and distribute verbatim opies of the Program's sour e ode as
you re eive it, in any medium, provided that you onspi uously and appropriately
publish on ea h opy an appropriate opyright noti e and dis laimer of warranty;
keep inta t all the noti es that refer to this Li ense and to the absen e of any
warranty; and give any other re ipients of the Program a opy of this Li ense
along with the Program.
You may harge a fee for the physi al a t of transferring a opy, and you may at
your option oer warranty prote tion in ex hange for a fee.
2. You may modify your opy or opies of the Program or any portion of it, thus
forming a work based on the Program, and opy and distribute su h modi ations
or work under the terms of Se tion 1 above, provided that you also meet all of
these onditions:
(a) You must ause the modied les to arry prominent noti es stating that you
hanged the les and the date of any hange.
(b) You must ause any work that you distribute or publish, that in whole or
in part ontains or is derived from the Program or any part thereof, to be
li ensed as a whole at no harge to all third parties under the terms of this
Li ense.
( ) If the modied program normally reads ommands intera tively when run,
you must ause it, when started running for su h intera tive use in the most
ordinary way, to print or display an announ ement in luding an appropriate
opyright noti e and a noti e that there is no warranty (or else, saying that
you provide a warranty) and that users may redistribute the program under
these onditions, and telling the user how to view a opy of this Li ense.
(Ex eption: if the Program itself is intera tive but does not normally print
su h an announ ement, your work based on the Program is not required to
print an announ ement.)
These requirements apply to the modied work as a whole. If identiable se tions
of that work are not derived from the Program, and an be reasonably onsidered
independent and separate works in themselves, then this Li ense, and its terms,
do not apply to those se tions when you distribute them as separate works. But
when you distribute the same se tions as part of a whole whi h is a work based on
the Program, the distribution of the whole must be on the terms of this Li ense,
whose permissions for other li ensees extend to the entire whole, and thus to ea h
and every part regardless of who wrote it.
Thus, it is not the intent of this se tion to laim rights or ontest your rights to
work written entirely by you; rather, the intent is to exer ise the right to ontrol
the distribution of derivative or olle tive works based on the Program.
151
In addition, mere aggregation of another work not based on the Program with
the Program (or with a work based on the Program) on a volume of a storage or
distribution medium does not bring the other work under the s ope of this Li ense.
3. You may opy and distribute the Program (or a work based on it, under Se tion
2) in obje t ode or exe utable form under the terms of Se tions 1 and 2 above
provided that you also do one of the following:
(a) A ompany it with the omplete orresponding ma hine-readable sour e ode, whi h must be distributed under the terms of Se tions 1 and 2 above on
a medium ustomarily used for software inter hange; or,
(b) A ompany it with a written oer, valid for at least three years, to give any
third party, for a harge no more than your ost of physi ally performing
sour e distribution, a omplete ma hine-readable opy of the orresponding
sour e ode, to be distributed under the terms of Se tions 1 and 2 above on
a medium ustomarily used for software inter hange; or,
( ) A ompany it with the information you re eived as to the oer to distribute
orresponding sour e ode. (This alternative is allowed only for non ommer ial distribution and only if you re eived the program in obje t ode or
exe utable form with su h an oer, in a ord with Subse tion b above.)
The sour e ode for a work means the preferred form of the work for making
modi ations to it. For an exe utable work, omplete sour e ode means all the
sour e ode for all modules it ontains, plus any asso iated interfa e denition les,
plus the s ripts used to ontrol ompilation and installation of the exe utable.
However, as a spe ial ex eption, the sour e ode distributed need not in lude
anything that is normally distributed (in either sour e or binary form) with the
major omponents ( ompiler, kernel, and so on) of the operating system on whi h
the exe utable runs, unless that omponent itself a ompanies the exe utable.
If distribution of exe utable or obje t ode is made by oering a ess to opy from
a designated pla e, then oering equivalent a ess to opy the sour e ode from
the same pla e ounts as distribution of the sour e ode, even though third parties
are not ompelled to opy the sour e along with the obje t ode.
4. You may not opy, modify, subli ense, or distribute the Program ex ept as expressly provided under this Li ense. Any attempt otherwise to opy, modify, subli ense
or distribute the Program is void, and will automati ally terminate your rights under this Li ense. However, parties who have re eived opies, or rights, from you
under this Li ense will not have their li enses terminated so long as su h parties
remain in full omplian e.
152
^
APENDICE
H. LICENC
A
5. You are not required to a ept this Li ense, sin e you have not signed it. However,
nothing else grants you permission to modify or distribute the Program or its
derivative works. These a tions are prohibited by law if you do not a ept this
Li ense. Therefore, by modifying or distributing the Program (or any work based
on the Program), you indi ate your a eptan e of this Li ense to do so, and all its
terms and onditions for opying, distributing or modifying the Program or works
based on it.
6. Ea h time you redistribute the Program (or any work based on the Program),
the re ipient automati ally re eives a li ense from the original li ensor to opy,
distribute or modify the Program subje t to these terms and onditions. You may
not impose any further restri tions on the re ipients' exer ise of the rights granted
herein. You are not responsible for enfor ing omplian e by third parties to this
Li ense.
7. If, as a onsequen e of a ourt judgment or allegation of patent infringement or
for any other reason (not limited to patent issues), onditions are imposed on you
(whether by ourt order, agreement or otherwise) that ontradi t the onditions
of this Li ense, they do not ex use you from the onditions of this Li ense. If
you annot distribute so as to satisfy simultaneously your obligations under this
Li ense and any other pertinent obligations, then as a onsequen e you may not
distribute the Program at all. For example, if a patent li ense would not permit
royalty-free redistribution of the Program by all those who re eive opies dire tly
or indire tly through you, then the only way you ould satisfy both it and this
Li ense would be to refrain entirely from distribution of the Program.
If any portion of this se tion is held invalid or unenfor eable under any parti ular
ir umstan e, the balan e of the se tion is intended to apply and the se tion as a
whole is intended to apply in other ir umstan es.
It is not the purpose of this se tion to indu e you to infringe any patents or other
property right laims or to ontest validity of any su h laims; this se tion has the
sole purpose of prote ting the integrity of the free software distribution system,
whi h is implemented by publi li ense pra ti es. Many people have made generous
ontributions to the wide range of software distributed through that system in
relian e on onsistent appli ation of that system; it is up to the author/donor to
de ide if he or she is willing to distribute software through any other system and
a li ensee annot impose that hoi e.
This se tion is intended to make thoroughly lear what is believed to be a onsequen e of the rest of this Li ense.
8. If the distribution and/or use of the Program is restri ted in ertain ountries either
by patents or by opyrighted interfa es, the original opyright holder who pla es
the Program under this Li ense may add an expli it geographi al distribution
153
limitation ex luding those ountries, so that distribution is permitted only in or
among ountries not thus ex luded. In su h ase, this Li ense in orporates the
limitation as if written in the body of this Li ense.
9. The Free Software Foundation may publish revised and/or new versions of the
General Publi Li ense from time to time. Su h new versions will be similar in
spirit to the present version, but may dier in detail to address new problems or
on erns.
Ea h version is given a distinguishing version number. If the Program spe ies
a version number of this Li ense whi h applies to it and \any later version", you
have the option of following the terms and onditions either of that version or of
any later version published by the Free Software Foundation. If the Program does
not spe ify a version number of this Li ense, you may hoose any version ever
published by the Free Software Foundation.
10. If you wish to in orporate parts of the Program into other free programs whose
distribution onditions are dierent, write to the author to ask for permission. For
software whi h is opyrighted by the Free Software Foundation, write to the Free
Software Foundation; we sometimes make ex eptions for this. Our de ision will
be guided by the two goals of preserving the free status of all derivatives of our
free software and of promoting the sharing and reuse of software generally.
NO WARRANTY
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS
NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED
BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE
THE PROGRAM \AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM
PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER
PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM
AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
154
^
APENDICE
H. LICENC
A
BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR

THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH
ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
END OF TERMS AND CONDITIONS
Referên ias Bibliogra as

[1 A do umenta ~ao sobre o pro essador Athlon K7 pode ser en ontrada nas paginas
do site do fabri ante, por exemplo nos URLs:
http://www.amd. om/produ ts/ pg/athlon/
http://www.amd. om/produ ts/ pg/athlon/te hdo s/
[2 Motherboards da Digitron para Athlon K7.

http://www.digitron. om.br/
http://www.digitron. om.br/eaaks.htm
http://www.digitron. om.br/mother.htm
[3 Motherboards da Tekram para Athlon K7.

http://www.tekram. om/
http://www.tekram. om/produ ts.asp
http://www.tekram. om/hot produ ts.asp?Produ t=K7KX-A
[4 Os swit hes estaqueaveis da 3COM podem ser en ontrados nos seguintes URLs:
http://www.3 om. om/produ ts/swit hes/sta kable.html
http://www.3 om. om/produ ts/swit hes/sw1100 3300 family.html
http://www.3 om. om/produ ts/dsheets/801701.html
[5 Estes links s~ao os do site do kernel do Linux, in luindo ao a esso por HTTP e por
FTP.
http://www.kernel.org/
http://ftp.kernel.org/
155
156
^

REFERENCIAS
BIBLIOGRAFICAS
[6 O primeiro dos links abaixo e a home page da distribui ~ao Debian. Os outros s~ao
os sites de onde se pode obter o software por meio de FTP ou HTTP, in luindo a
parte prin ipal da distribui ~ao, a parte ontendo softwares de en ripta ~ao e o site
om os updates de seguran a.
http://www.debian.org/
ftp://ftp.debian.org/
ftp://nonus.debian.org/
ftp://se urity.debian.org/
[7 Este link e a home page do projeto Etherboot, que usamos para o boot remoto dos
nos atraves da rede.
http://etherboot.sour eforge.net/
[8 Estes links s~ao as home pages dos projetos LinUSP e LinORG da Universidade de
S~ao Paulo. Estas paginas est~ao atualmente fora do ar mas devem voltar em breve.
http://linusp.usp.br/
http://linorg.usp.br/
[9 A home page do projeto PVM:

http://www.epm.ornl.gov/pvm/pvm home.html
[10 O uni o livro publi ado sobre PVM, \PVM: Parallel Virtual Ma hine, A Users' Guide and Tutorial for Networked Parallel Computing", esta disponvel para download
em PS ou online em HTML em:
http://www.netlib.org/pvm3/book/pvm-book.html
[11 Links uteis sobre o MPI:

http://www.netlib.org/mpi/
http://www.mpi.nd.edu/lam/
http://WWW.ERC.MsState.Edu/labs/hp l/proje ts/mpi/
[12 Existe um urso on-line de MPI, do quel se pode obter o material em PS de gra a,
mediante registro pela rede. Os links s~ao:
^

REFERENCIAS
BIBLIOGRAFICAS
157
http://www.ep .ed.a .uk/epi /

http://www.ep .ed.a .uk/ep -te / ourse-pa kages/
[13 Neste site podem ser en ontrados os ben hmarks do Linpa k. Ele lista informa ~ao
sobre desempenho numeri o de variadas maquinas e pro essadores. Os ben hmark
Linpa k s~ao os que interessam mais para apli a ~oes ient as e ha uma vers~ao
espe a para maquinas paralelas. Ha tambem no site a lista das 500 maquinas
mais rapidas do mundo.
http://performan e.netlib.org/
http://performan e.netlib.org/performan e/html/PDStop.html
http://performan e.netlib.org/ben hmark/top500.html

HowtoPMC Ps

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HowtoPMC Ps

Transféré par

Droits d'auteur :

Formats disponibles

B

Como Construir e Operar o Seu Pr

aqui na terra dos Sa is!

Copyright 2001 by Jorge L. deLyra

Avalia ~ao da Situa ~ao . . . . . . . . .

Des ri ~ao Geral da Solu ~ao Proposta . . .

Como o Sistema todo Opera . . . . . . .

4.1 Uso do Sistema pelos Usuarios . . . . . . . .

5.1 Algumas Pondera ~oes e Justi ativas . . . . . .

Transi ~ao dos Servidores de NFS . .

B.8 Estante para Montagem dos Nos . . . . . . . . . . . . . . . . . . . . . . . 82

C.1 Bibliote a de Arquivos de Con gura ~ao .

D.1 Re eitas de Montagem de Hardware . . . . . . . . . . .

Parti ionamento dos Dis os . . . . . .

em todo o mundo, atalisado e apitaneado pelo enorme su esso do primeiro sistema

1.2 Proposta deste Do umento

1.3 Quali a o~es e Limita o~es do Autor

1.4 Quali a o~es e Limita o~es do Leitor

do sistema. Para se informar subsequentemente sobre os pro edimentos de instala ~ao o

em qualquer espelho da distribui ~ao. O link para o site original e

1.5 Estrategia de Leitura deste Do umento

2.1 Des ri ~ao Geral da Solu ~ao Proposta

2.2 Fun ~ao de ada Componente do PMC

~ DE CADA COMPONENTE DO PMC

2.3 Des ri ~ao Detalhada dos Componentes

~ DETALHADA DOS COMPONENTES

Figura 2.2: Ilustra ~ao de um no de pro essamento, visto de ima.

menos rapido (e aro) dependendo de suas ne essidades de omuni a ~ao entre os

2.4 Des ri ~ao do Pro esso de Montagem

2.4.1 Montagem da Motherboard

2.4.2 Montagem das Pe as no Gabinete

soquete apropriado da motherboard. Pode-se instalar tambem uma unidade CDROM

2.4.3 Conex~oes ao Gabinete e Opera ~ao

2.5. DETALHES DA MONTAGEM DO FRONT-END

re omenda o uso de no-breaks.

2.5 Detalhes da Montagem do Front-End

Endere o Jumper 3 Jumper 2 Jumper 1 Jumper 0

2.6 Detalhes da Montagem do Servidor

2.7. DETALHES DA MONTAGEM DO TERMINAL

2.7 Detalhes da Montagem do Terminal

2.8 Detalhes da Montagem dos Nos

Figura 2.3: Um modulo da estante de madeira de 209 m de altura para a montagem

Figura 2.5: Diagrama mostrando os bot~oes de ontato moment^aneo e os leds soldados

2.9. MONTAGEM DO EQUIPAMENTO DE REDE

2.9 Montagem do Equipamento de Rede

3.2. PAPEL DE CADA ELEMENTO DE SOFTWARE

3.2 Papel de ada Elemento de Software

arquivos diretamente em seus homes em suas maquinas de uso geral de origem, e

3.3 Pro edimento Geral de Instala ~ao

em qualquer espelho da distribui ~ao. O link para o site original e

3.4 Pro edimento de Compila ~ao do Kernel

Vo ^e pode obter esta vers~ao do kernel usando o link abaixo.

Ja dentro do diretorio /boot/ devemos ter o que segue abaixo.

System.map -> System.map-2.2.18

Name Part Type FS Type

Desta forma o onteudo da raiz do sistema e mantido estavel, independente da vers~ao do

3.5 Detalhes da Instala ~ao do Front-End

Used Available Use% Mounted on

3.6 Detalhes da Instala ~ao do Servidor

Name Part Type FS Type

Used Available Use% Mounted on

Name Part Type FS Type

blers, bibliote as de linkagem estati a e din^ami a e editores de linkagem ne essarios

Como Construir e Operar o Seu Pr

Avalia ~ao da Situa ~ao . . . . . . . . .

Des ri ~ao Geral da Solu ~ao Proposta . . .

4.1 Uso do Sistema pelos Usuarios . . . . . . . .

5.1 Algumas Pondera ~oes e Justi ativas . . . . . .

Transi ~ao dos Servidores de NFS . .

B.8 Estante para Montagem dos Nos . . . . . . . . . . . . . . . . . . . . . . . 82

C.1 Bibliote a de Arquivos de Congura ~ao .

1.3 Quali a o~es e Limita o~es do Autor

1.4 Quali a o~es e Limita o~es do Leitor

do sistema. Para se informar subsequentemente sobre os pro edimentos de instala ~ao o

em qualquer espelho da distribui ~ao. O link para o site original e

1.5 Estrategia de Leitura deste Do umento

2.1 Des ri ~ao Geral da Solu ~ao Proposta

2.2 Fun ~ao de ada Componente do PMC

2.3 Des ri ~ao Detalhada dos Componentes

Figura 2.2: Ilustra ~ao de um no de pro essamento, visto de ima.

menos rapido (e aro) dependendo de suas ne essidades de omuni a ~ao entre os

2.4 Des ri ~ao do Pro esso de Montagem

2.4.2 Montagem das Pe as no Gabinete

soquete apropriado da motherboard. Pode-se instalar tambem uma unidade CDROM

2.4.3 Conex~oes ao Gabinete e Opera ~ao

Endere o Jumper 3 Jumper 2 Jumper 1 Jumper 0

2.8 Detalhes da Montagem dos Nos

Figura 2.3: Um modulo da estante de madeira de 209 m de altura para a montagem

arquivos diretamente em seus homes em suas maquinas de uso geral de origem, e

3.3 Pro edimento Geral de Instala ~ao

em qualquer espelho da distribui ~ao. O link para o site original e

3.4 Pro edimento de Compila ~ao do Kernel

Ja dentro do diretorio /boot/ devemos ter o que segue abaixo.

Desta forma o onteudo da raiz do sistema e mantido estavel, independente da vers~ao do

3.5 Detalhes da Instala ~ao do Front-End

3.6 Detalhes da Instala ~ao do Servidor

blers, bibliote as de linkagem estati a e din^ami a e editores de linkagem ne essarios

3.7 Detalhes da Instala ~ao do Terminal

Ambiente de desenvolvimento: trata-se dos pre-pro essadores, ompiladores, assem-

blers, bibliote as de linkagem estati a e din^ami a e editores de linkagem ne essarios

3.8 Detalhes da Instala ~ao dos Nos

4. No servidor, abra ada arquivo tar em um diretorio apropriado nos lesystems do

3.9 Detalhes da Instala ~ao da Rede

range de endere os:

Ja uma rede privada ompleta, de lasse B, seria ongurada assim:

4.2 Geren iamento e Administra ~ao

Alem dos upgrades rotineiros de kernel e de distribui ~ao, as tarefas administrativas

4.2.2 Instala ~ao de Novos Nos

4.2.3 Monitoramento dos Nos

4.2.4 Problemas om um dos Nos

mudan a do kernel de boot ou om mudan as adequadas no arquivo de ongura ~ao do

4.3.3 Comentarios sobre ada Componente

Upgrades do Servidor: As ne essidades de atualiza ~ao do servidor s~ao menores do

que as do front-end. Entretanto, e importante manter o kernel atualizado. Ja as

5.2 Preo upa o~es om a Infra-Estrutura

5.2.2 Temperatura e Refrigera ~ao

omo veremos na se ~ao 5.3.2.

pre o ainda e bem menor do que o investimento orrespondente para o aso de

5.3.2 Possveis Desenvolvimentos Te nologi os

5.4 Sobre a Utiliza ~ao dos Re ursos

bibliogra os que podem ser en ontrados ao nal deste do umento.

5.4.2 Filosoa de Uso e Compartilhamento

A arquitetura do PMC foi on ebida de forma a fa ilitar ao maximo o ompartilhamento

5.5 Outras Apli a o~es das Mesmas Ideias

5.6 Variadas Alternativas Possveis

5.6. VARIADAS ALTERNATIVAS POSSIVEIS

Em seguida, e ne essario fazer um oppy bootavel om esta imagem, o que vo ^e pode

A.3 Aquisi ~ao de um Gravador de Eprom

e o telefone e 273-8822. Tambem e possvel enviar orreio eletr^oni o para

ontroni ontroni . om.br

Des ri ~ao da pe a

Des ri ~ao da pe a

B.8 Estante para Montagem dos Nos

C.1 Bibliote a de Arquivos de Congura ~ao

tema, permitindo desta forma o livre tr^ansito do usuarios administrativo dentro do

auto.home: Fun ~ao: denir as montagens automati as dentro do diretorio /home/;

sera usado para a montagem dos homes dos usuarios.

Lo aliza ~ao: diretorio /et /.