Você está na página 1de 8

3-Configurando um sistema de ameba

3.1. Introdução
Existem muitos aspectos de um sistema Amoeba que são configuráveis. Eles serão discutidos na
ordem em que precisam ser confrontados logo após a instalação de um novo sistema.

O primeiro problema geralmente é adicionar novos hosts ao sistema para que haja mais de um host
Amoeba. Isso é necessário, pois há vários servidores necessários para que o sistema funcione
satisfatoriamente, e eles terão um desempenho muito melhor se não forem todos executados no
mesmo host. Observe também que, após a instalação inicial do Amoeba, o servidor de arquivos está
no conjunto de processadores. Ele deve ser removido do pool assim que outros processadores
estiverem disponíveis para executar o trabalho.

O próximo passo é configurar os vários servidores que estão quase sempre em demanda ou que são
necessários para um bom funcionamento do sistema. Alguns servidores podem ser replicados ou
podem replicar seus dados e há um servidor especial que fornecerá replicação preguiçosa de objetos,
além de coleta de lixo de objetos que não estão mais em uso ou acessíveis no gráfico de diretórios.

N.B. É muito importante para o desempenho e a segurança da Amoeba que um servidor de execução
(A) seja iniciado. Sob nenhuma circunstância este servidor deve ser omitido.

3.2. Configurando Hosts de Amoeba

3.2.1. Adicionando Novos Hosts


Na Amoeba, os usuários normalmente não estão cientes de quais processadores estão executando
seus trabalhos ou até mesmo quantos processadores estão presentes. No entanto, o sistema precisa
saber o que

hardware está disponível se for para usá-lo. Adicionar um novo host a um sistema Amoeba é uma
operação razoavelmente direta.

Instale o hardware (de acordo com as instruções do fabricante) e conecte-o à rede. Em seguida,
determine seu endereço de rede. (Amoeba atualmente suporta Ethernet como meio de rede e,
portanto, a descrição a seguir é orientada para isso.) A parte difícil é pensar em um nome pelo qual o
host é conhecido. Os usuários geralmente não verão esses nomes, mas o administrador do sistema
precisará de alguma forma de endereçar uma máquina específica para carregar um novo kernel nela.
O sistema também precisa de um nome (na verdade, um recurso) para uma máquina, para que possa
iniciar processos nela. Há muitas diretrizes para máquinas de nomeação, a mais importante das quais
é, não nomeá-lo após o fabricante da máquina. Escolha um tema, como tipos de barco ou nomes de
dança. Como você pode ter dezenas de processadores de pool, pode ser uma boa ideia numerá-los.
Por exemplo, todos os processadores mc68000 podem obter os nomes pogo00 a pogo99. N.B. Os
nomes de host não devem conter o caractere ".". Caso contrário, tais hosts serão ignorados pelo
servidor run (A) e pelo mecanismo de criação do processo.

A próxima etapa é criar um recurso para o novo host e instalá-lo no diretório / super / hosts. Isso é
feito usando o comando mkhost (A). Suponha que alguém deseje criar uma entrada para o host
pogo00 que tenha o endereço Ethernet 00: 00: 2c: 11: ab: 09, então o
comando

mkhost / super / hosts / pogo00 00: 00: 2c: 11: ab: 09

alcançaria isso. É importante certificar-se de que o recurso tenha o modo correto. Para operação
normal, o modo FF: 2: 4 é recomendado. Isso impede que usuários sem privilégios acessem discos e
memória do kernel e destruam processos que não possuem. Para definir o modo, você deve digitar o
comando

chm ff: 2: 4 / super / hosts / pogo00

Agora deve ser possível baixar um kernel Amoeba no host e examinar o diretório do kernel (usando
dir (U)). O download do kernel dependerá do tipo de hardware. As máquinas Intel 80386, 80486 e
Pentium podem ser inicializadas a partir do disquete. Os hosts Sun 3 e Sun 4 devem ser inicializados
usando tftp (A). Se um sistema já estiver em execução, ele pode ser reinicializado usando a
reinicialização (A). Observe que as máquinas Sun 3 não aceitam o comando de reinicialização (A).

As etapas subseqüentes tomadas agora dependem da função do novo host. Se for para ser um
processador de conjunto, o recurso para o host precisa ser colocado em um ou mais diretórios de
conjunto.

Por exemplo, se os novos hosts forem chamados pogo00 e forem uma máquina i80386, os comandos

obter / super / hosts / pogo00 | colocar / super / pool / i80386 / pogo00 chm ff: 2: 4 / super / pool /
i80386 / pogo00

instalará o recurso de hosts no pool. Atualmente, os diretórios do pool de processadores são


agrupados por arquitetura e são encontrados em / super / pool. Ao inserir o recurso em um diretório
de pool, todos os usuários que tiverem esse diretório em seu diretório / profile / pool poderão

para usar esse processador pool para executar seus trabalhos. Observe que é possível ter mais de um
pool para uma arquitetura específica. Um pode conter metade das máquinas mc68000 e outro a outra
metade. Além disso, um processador de pool pode estar em mais de um pool.

Se for necessário que um host responda aos protocolos ARP reverso (RARP) e / ou TFTP (por exemplo,
computadores Sun), ele precisará ter seu endereço Ethernet e nome do host digitados no arquivo /
etc / ethers. Para fazer isso, o arquivo / super / unixroot / etc / ethers deve ser editado. (Isto é

na verdade, o mesmo arquivo como / etc / ethers, mas o nome do caminho / super / unixroot / etc /
ethers dá permissão de gravação para o arquivo e o outro nome do caminho não.) Continuando o
exemplo anterior, a linha

00: 00: 2c: 11: ab: 09 pogo00

deve ser adicionado ao arquivo.

Se o host também precisar usar os protocolos de rede TCP / IP ou UDP (por exemplo, inicialização por
TFTP ou para se comunicar com hosts UNIX ou pela rede de longa distância) ou por algum motivo
precisar ter seu nome mapeado para um endereço da Internet então será necessário atribuir um
endereço da Internet ao host. (Não basta criar endereços da Internet. Obtenha um conjunto através
dos canais apropriados.) O nome do host e o endereço da Internet devem ser inseridos no arquivo /
etc / hosts. Isso é feito editando / super / unixroot / etc / hosts. No exemplo, se tivéssemos atribuído
o número de Internet 192.31.237.44 a pogo00, a linha

192.31.237.44 pogo00

deve ser adicionado ao final do arquivo / super / unixroot / etc / hosts.

Se o arquivo tiver que ser inicializado usando o TFTP, também será necessário adicionar uma entrada
ao diretório / super / admin / tftpboot, que é a capacidade para o arquivo que contém o kernel ser
inicializado no host. O nome do arquivo inserido no diretório tftpboot depende muito do sistema a ser
inicializado. A Sun usa o endereço da Internet escrito como um número hexadecimal. (Para o Suns,
portanto, é necessário fornecer a cada máquina um endereço na Internet para que seja inicializado
usando TFTP.) No exemplo acima, o arquivo seria chamado C01FED2C para um Sun 3,
C01FED2C.SUN4C para um Sun4c e C01FED2C.SUN4M para uma máquina Sun4m.

Uma complicação final da inicialização via TFTP é iniciar um servidor RARP e TFTP para inicializar os
novos hosts. É necessário instalar um kernel especial (no host diferente do servidor bullet) que
contém o servidor TCP / IP. Este kernel pode ser o kernel tcpip ou o kernel smbulip (abreviação de
bullet pequeno com TCP / IP). Veja installk (A) para saber como instalar este kernel no disco rígido.
Depois disso, o servidor de inicialização (veja boot (A)) pode ser usado para iniciar os servidores RARP
e TFTP e inicializar os outros hosts. Veja abaixo os detalhes de onde encontrar o Bootfile.

Uma configuração de exemplo para os servidores RARP e TFTP pode ser encontrada no arquivo de
inicialização padrão. Se a máquina do servidor de arquivos contiver memória insuficiente para
executar todos esses servidores, os outros hosts terão que ser inicializados a partir do UNIX.

Outros sistemas de inicialização podem exigir ainda outro suporte, mas os exemplos acima devem
fornecer indicação suficiente dos passos envolvidos na adição de um novo host. Neste estágio, é
importante inicializar o processador do conjunto e os hosts da estação de trabalho.

Se for adicionada uma nova estação de trabalho, é importante iniciar um processo de login que
permita o login dos usuários. Para isso, será necessário informar ao servidor de inicialização (ver boot
(A)) para iniciar o login do programa (A) no aquela máquina quando ela surge. Os exemplos no
Bootfile (encontrado em

o diretório / super / admin / bootinfo) fornecido com o sistema deve indicar como fazer isso.

A seqüência básica de etapas é:

1. Adicione uma entrada adequada ao Bootfile.

2. Execute o iboot (A). Observe que você nunca deve usar a opção -l, a menos que esteja instalando
um novo disco.

Um comando da forma

iboot -f Bootfile / super / hosts / xxx / vdisk: 02

(onde xxx é o nome do host com a partição de disco do servidor de inicialização) deve ser tudo o que é
necessário.
3. Execute o comando

bota reinicializar / super / cap / bootsvr / xxx

Isso deve indicar sucesso se o Bootfile for válido. Caso contrário, não reinicialize o sistema sob
nenhuma circunstância. Em vez disso, corra

std status / super / cap / bootsvr / xxx

para descobrir o problema e, em seguida, corrija o Bootfile e repita o processo de instalação.

3.2.2. Excluindo um host


A exclusão de um host é basicamente a operação inversa da instalação. Certifique-se de que o
servidor de inicialização (A) não use mais o host para iniciar um processo. Em seguida, desative o
kernel na máquina.

Em seguida, exclua a entrada de diretório desse host dos diretórios / super / hosts e pool.

Exclua a entrada para o host dos arquivos / etc / hosts e / etc / ethers. Exclua todas as entradas para o
host dos diretórios de inicialização, como / super / admin / tftpboot.

3.2.3. Substituindo um host


Se você substituir um host por um novo hardware, várias coisas podem mudar e precisam ser
atendidas.Por exemplo, se a nova máquina tiver um endereço Ethernet diferente, as entradas em /
super / hosts e os diretórios do conjunto devem ser recriados e o arquivo / etc / ethers modificado
para refletir o novo endereço. Se o endereço Ethernet permanecer inalterado, mas a arquitetura da
máquina for diferente, pode ser necessário mover a máquina para um diretório de pool diferente.

3.3. Configuração do Servidor


Existem vários servidores que são essenciais para a boa saúde e operação contínua de um sistema
Amoeba. Alguns deles são construídos no kernel, mas a maioria deles é executada no espaço do
usuário. É importante garantir que eles estejam todos altamente disponíveis. Isso é feito replicando os
servidores, certificando-se de que eles sejam reiniciados rapidamente em caso de falha ou ambos.
Vamos começar com uma recuperação rápida. Existe um servidor, conhecido como o servidor de
inicialização, cuja função é garantir que os servidores registrados nele estejam em execução. Ele faz
isso consultando regularmente cada servidor. A frequência com que ele pesquisa cada servidor é
definida no momento do registro.

Se o servidor não responder dentro de um período especificado, ele tentará reiniciar o servidor. Para
detalhes de como registrar um servidor com o servidor de inicialização, veja boot (A). O sistema, como
instalado a partir da fita, possui um servidor de inicialização. Isso é iniciado a partir do kernel como o
primeiro processo do usuário e

A primeira função é iniciar o servidor de diretórios e o daemon de login. Obviamente, é possível ter
dois ou mais servidores de inicialização e cada servidor de inicialização registrar-se em outro, de modo
que, se um deles for desativado, ele será reiniciado.
Infelizmente, ainda não é possível garantir que um kernel seja baixado em uma máquina usando o
servidor de inicialização. Isso ainda deve ser feito à mão. Esse problema pode ser resolvido em uma
versão futura do Amoeba, embora alguns aspectos dele possam estar além do controle do software,
como a reinicialização de uma máquina que caiu ou a detecção de que houve uma falha de hardware
na máquina em questão.

A replicação de objetos e, em particular, servidores, é uma maneira muito eficaz de fornecer alta
disponibilidade. Certos serviços são cruciais para o funcionamento do sistema. Eles são o servidor de
execução, o servidor do horário do dia, o servidor de números aleatórios, o Bullet Server e o servidor
Soap.

Um servidor essencial para o desempenho da Amoeba é o servidor de execução (A). A função deste
servidor é selecionar um processador no qual um processo deve ser executado. Se o servidor de
execução não estiver presente, isso pode levar muito tempo. É também responsável pela
implementação do exclusivo

acessar recursos do servidor de reservas (ver reserve􀀀 svr (A)). O servidor de execução deve ser
iniciado pelo servidor de inicialização depois que o servidor de diretório estiver em execução. Ele
preferencialmente não deve ser executado no mesmo host que o servidor de arquivos. Veja a página
de manual do servidor de execução para obter detalhes sobre como

para colocar os vários pools de processadores sob seu controle. Isso não é automático.

O servidor de hora do dia e o servidor de números aleatórios são servidores baseados em kernel e,
portanto, estão disponíveis se o kernel que os contém estiver ativo. No entanto, é perfeitamente
possível ter esses servidores em mais de um kernel. Na verdade, é altamente recomendável. O
servidor que todo mundo usa é conhecido como o servidor padrão. No caso do servidor do horário do
dia, ele é registrado como / profile / cap / todsvr / default. No entanto, se o host que contém o
servidor do horário do dia ficar inativo por algum motivo, muitos programas que dependem desse
servidor falharão se um novo servidor não for instalado rapidamente. A melhor maneira de fazer isso
é ter um segundo servidor disponível e permitir que os vários servidores de inicialização consultem
regularmente o recurso / super / cap / todsvr / default. O primeiro a detectar a ausência do servidor
pode substituir imediatamente a capacidade existente com a capacidade de um servidor de horário
do dia que ainda está ativo. Uma estratégia idêntica é necessária para o servidor de números
aleatórios.O programa de login é chamado de login (A). Isso também pode ser iniciado pelo servidor
de inicialização. Normalmente é usado apenas em um terminal convencional. Se a estação de trabalho
estiver executando um servidor X windows, o xlogin deverá ser usado. Também é uma boa ideia
deixar o servidor de inicialização O servidor X está sendo executado na estação de trabalho na qual o
xlogin deve operar. Observe que o xlogin não precisa ser executado na estação de trabalho na qual ele
opera, mas é mais confiável dessa maneira. Em seguida, o programa de login estará presente sempre
que a estação de trabalho estiver ativa. Será contando com a quantidade mínima de outro software e
hardware funcionando corretamente. No caso de um terminal X, isso não é possível e o xlogin deve
ser executado em algum outro processador. É possível ter mais de um Bullet Server em um sistema.
Atualmente, existe exatamente um Bullet Server padrão, mas é possível registrar muitos recursos no
diretório / super / cap / bulletsvr sob o nome de cada servidor e, em seguida, vincular um deles ao
nome default. Então, se o padrão cair, é possível usar o servidor de inicialização para alternar
automaticamente para um servidor alternativo. Infelizmente, os arquivos que estão no servidor com
falha ficarão indisponíveis até serem reiniciados. Também é possível permitir que usuários diferentes
tenham um Bullet Server padrão diferente (e outros servidores padrão, para esse propósito) fazendo
versões diferentes do diretório / super / cap e instalando-os em um diretório de usuário / perfil / cap
específico, já que é o nome do caminho que os usuários usam para acessar as informações.

Existem várias vantagens em ter mais de um Bullet Server. Isso significa que um servidor que usa
explicitamente um Bullet Server para armazenar dados pode replicá-lo em um segundo servidor.
Então, se um Bullet Server ficar inativo, o servidor poderá continuar funcionando. Desde o servidor
Soap

permite que vários recursos de um objeto sejam armazenados em uma única entrada de diretório; há
outra vantagem em ter mais de um Bullet Server. É possível fazer replicação preguiçosa de arquivos
de um Bullet Server para outro, de modo que, usando apenas uma entrada de diretório, o original ou
sua réplica possam ser recuperados, dependendo da disponibilidade dos servidores de arquivos. Para
auxiliar na replicação de objetos, existe um servidor especial chamado gerenciador de objetos (veja
om (A)) que suporta replicação e coleta de lixo. Será descrito em breve.

O servidor de diretório Soap (veja soap (A)) está no centro do gerenciamento de objetos sob o
Amoeba. Ele mapeia uma string ASCII para um conjunto de recursos para um objeto. O Soap Server
pode ser configurado de várias formas, dependendo do hardware disponível e dos requisitos de
disponibilidade do serviço. Junto com o Bullet Server, é um dos servidores mais importantes do
sistema, pois fornece acesso a todos os objetos. Depende de um servidor de hora do dia, um servidor
aleatório e pelo menos um Bullet Server. Note que não usa os servidores padrões, mas sua escolha de
servidores é corrigida quando é iniciada.

É possível duplicar um servidor de sabão. Se instalado corretamente, é possível que duas cópias de
sabão compartilhem a mesma base de dados e processem as solicitações. (Cada um mantém sua
própria administração, no entanto.) Atualizações são passadas para o parceiro por meio de um
protocolo especial. Se um dos servidores ficar inativo, o outro continuará a atender às solicitações.
Quando o outro retornar, ele primeiro atualizará sua cópia dos dados de administração antes de
prosseguir.

O Soap Server também pode duplicar sua base de dados em mais de um Bullet Server. Isso pode ser
feito independentemente de o Soap Server estar ou não duplicado. Há também um comando especial
chbul (A) para alterar qualquer um dos dois Bullet Servers que o soap está usando. Iniciar sabão é um
negócio bastante difícil e geralmente é melhor realizado pelo servidor de inicialização. (Na verdade,
na ausência de outro Soap Server, o servidor de inicialização é a única maneira de iniciar o soap!) É
vital que, ao instalar uma nova versão do Soap Server, você acerte pela primeira vez se tiver apenas
um Soap Servidor. Se o sabão for executado no modo de duas cópias, será possível eliminar um dos
servidores e tentar substituí-lo pela nova versão. Se isso falhar, ainda haverá outro Servidor de Soap
em execução para permitir uma segunda chance de obter a instalação correta. Observe que

esse mecanismo também permite a instalação de um novo servidor de diretório com quase zero
tempo de inatividade. Primeiro substitua um dos servidores e abra a nova versão. Em seguida, mate o
outro e abra a nova versão. A única vez que o serviço está fora do ar é durante a sincronização entre
os dois servidores quando o segundo é iniciado e isso é normalmente uma questão de alguns
segundos. O gerenciador de objetos (veja om (A)) é usado para duas funções primárias. O primeiro é
replicar objetos em vários servidores. A segunda é oferecer suporte à coleta de lixo. (O último é
necessário, pois os servidores não têm como saber quais de seus objetos ainda são necessários. Se
alguém perder a capacidade de um objeto, ele poderá continuar a consumir recursos para sempre,
pois

o servidor nunca ouvirá a perda. Consulte o capítulo Manutenção de rotina para obter mais detalhes.)
O Om trabalha percorrendo regularmente todo o gráfico de pastas Soap e examinando cada entrada.
Se ele contiver um objeto para um servidor que deve ser replicado, ele será replicado. Também toca
em cada objeto (veja std (L)). Isso redefine o tempo de vida de cada objeto tocado ao máximo. (Isso
também acontece sempre que um objeto é acessado.) Depois de tocar todos os objetos, ele emite

comando para os servidores relevantes para envelhecer todos os seus objetos, reduzindo sua vida útil
em um. Qualquer objeto cujo tempo de vida chega a zero é destruído pelo seu servidor. O servidor
TCP / IP (consulte ipsvr (A)) é usado para converter entre o protocolo de rede Amoeba e o TCP / IP.
Isso é muito útil para comunicação com hosts na Internet, terminais X ou outros sistemas operacionais
na mesma rede. Para instalar um servidor TCP / IP, siga as instruções na página de manual do servidor.

3.4. Adicionando novos usuários


Dar aos novos usuários acesso à Amoeba é extremamente simples. Tem dois aspectos para isso. A
primeira é criar um diretório inicial e as informações relevantes para um novo usuário, para que
possam efetuar login.

A segunda refere-se a permitir o acesso à Amoeba de hosts UNIX usando o protocolo de rede
Amoeba. Para que os usuários acessem suas contas do UNIX, eles precisam de um arquivo em seu
diretório pessoal chamado .capability, que contém a capacidade de sua raiz Amoeba.

diretório.

Criar uma conta para um novo usuário é feito com o comando newuser (A). Cria um novo diretório
com o nome da nova conta no diretório / super / users. Este diretório então se torna o diretório raiz
do novo usuário. Ou seja, ele se torna o diretório que o novo usuário considerará como /. Em seguida,
ele constrói um gráfico de diretório sob a nova conta com links para diretórios de conjuntos e o
diretório de perfil. Ele também criará links para os diretórios de emulação do UNIX, como / bin e / etc.
Todos os recursos vinculados a diretórios públicos têm direitos restritos para que as informações
públicas não possam ser modificadas ou destruídas. Como opção, é possível dar a capacidade para o
diretório / super para um novo usuário. No entanto, esse recurso permite que o usuário grave e
destrua a permissão para todo o gráfico de diretório, de modo que ele não deva ser concedido a
pessoas não confiáveis ou pessoas que não entendem a natureza do sistema de diretórios. (Como
pode haver circuitos e links arbitrários no gráfico de diretórios, é fácil iniciar uma caminhada recursiva
através do gráfico que toca muito mais objetos do que o esperado!)

Observe que o comando newuser pode ser executado a partir do UNIX por alguém com o recurso
super para o gráfico de diretório ou pode ser executado sob Amoeba pelo administrador do sistema
com login como Daemon. A nova senha do usuário será solicitada no final do processo. o

A senha é armazenada em formato criptografado no arquivo Environ no novo diretório raiz do


usuário.

(Veja chpw (U) para mais detalhes sobre a alteração de senhas.)


O segundo aspecto da adição de um novo usuário é a possibilidade de acessar a Amoeba a partir do
UNIX. Nesse caso, em vez de obter o recurso para o diretório raiz fornecendo uma senha, o recurso
para o diretório raiz é armazenado no arquivo $ HOME / .capability. Existe um comando chamado
sendcap (A) que pode ser executado por alguém com o recurso super para o gráfico de diretório e isso
enviará o arquivo de capacidade (uuencoded) ao usuário junto com instruções sobre como instalá-lo.
Há, é claro, um problema de galinha e ovo aqui para aqueles que instalaram a Amoeba usando a fita
de instalação. Eles precisam obter o primeiro arquivo de capacidade instalado no UNIX antes que o
comando sendcap (ou qualquer outro comando Amoeba no UNIX) possa acessar o Amoeba. A
maneira mais fácil de fazer isso é usar o comando.

c2a /

para imprimir a capacidade de / sob Amoeba e, em seguida, criar um arquivo binário chamado
.capability usando o programa inverso a2c em seu diretório inicial no UNIX com o conteúdo binário
conforme a saída de c2a. Escusado será dizer que não é uma boa idéia fazer isso enquanto outros
estão por perto e capazes de tomar nota da capacidade impressa. Certifique-se de que o arquivo
.capability no UNIX tenha o modo 400.