Instalação de softwares em uma rede Unix heterogênea

Universidade Federal de Pernambuco
Departamento de Computação

Luis Carlos de Sousa Menezes
Fábio Nogueira de Souza

Abstract

A instalação e manutenção de softwares em um sistema heterogêneo costuma ser uma tarefa bastante árdua para os administradores de sistema, os quais necessitam dar suporte para as versões distintas de um mesmo software desenvolvidas para as várias arquiteturas que compõem a rede, e cuidar para que essas instalações façam um bom uso dos seus recursos. Nesse paper apresentamos um conjunto de regras que podem ser utilizadas para simplificar a tarefa de administração desses softwares.

1 - Introdução:

Em um sistema de redes é uma característica desejável que o usuário tenha uma visão uniforme do comportamento do sistema. Essa característica poderia ser alcançada usando-se um ambiente completamente homogêneo formado por máquinas de mesma arquitetura e sistema operacional, e que compartilhem um mesmo servidor de arquivos. Essa abordagem possui diversas desvantagens tais como baixa tolerância a falhas e dependência de um único de fornecedor, não sendo, por isso, muito difundida.

Para fornecer essa visão uniforme ao usuário, um sistema heterogêneo deve possuir as seguintes características:

• Todas as máquinas do sistema devem reconhecer o usuário e responder de maneira uniforme aos seus comandos.
• Os arquivos privados dos usuários devem ser acessados em todas as máquinas da rede sob o mesmo nome.

As tarefas de prover o acesso dos usuários nas máquinas da rede e distribuição dos seus arquivos podem ser realizadas através de serviços de rede especializados como NIS e NFS.

Para que todas as máquinas respondam de maneira uniforme é necessário que duas coisas ocorram:

• Todas as máquinas devem possuir um sistema operacional que forneça um conjunto de serviços básicos comuns, essa característica é bem resolvida nos sistemas operacionais UNIX pois estes possuem um conjunto de comandos e utilitários básicos que são aceitos por todas as implementações.
• Todas as máquinas devem conter o mesmo conjunto de softwares instalados.

A manutenção do mesmo conjunto de softwares instalado em todas as máquinas do sistema e funcionamento eficiente do mesmo é uma tarefa difícil. Contudo, alguns objetivos podem ser estabelecidos no sentido de se conseguir um desempenho adequado do sistema:

1. Garantir tolerância a falhas, para isso o administrador deve instalar softwares de forma a garantir que não apareçam dependências entre máquinas da rede que possam comprometer sua confiabilidade
2. O administrador deve preparar scripts de instalação que permitam a instalação de cada software para todas as arquiteturas possiveis, e esta instalação deve fornecer o mesmo ambiente para todas as plataformas de forma que o usuário não perceba a diferença entre duas plataformas distintas.
3. Deve-se colocar mecanismos que permitam identificar todos os arquivos pertencentes a um determinado software
4. Fazer um bom uso dos recursos disponíveis na rede, isso significa gerar copias das versões dos softwares de forma a minimizar a carga dos servidores e o espaço em disco necessário para armazenar os softwares.
5. Permitir delegar a outros usuários a tarefa de manter um conjunto de softs diminuindo o trabalho do administrador.

Para que se possa alcançar estes objetivos de uma forma simplificada, existe um conjunto de técnicas bem conhecido e divulgado que será abordado no restante deste paper.

2 - Técnicas Para Instalação de Pacotes de Software em Redes Unix Heterogêneas:

Esta seção apresenta de forma resumida algumas das técnicas utilizadas para instalação de pacotes de softwares em ambientes heterogêneos.Muito do que aqui é apresentado já se tornou um processo quase “padrão” na instalação de softwares neste tipo de ambiente. Alguns detalhes apresentados baseiam-se no modelo adotado pela Universidade de Edinburgo.

2.1 Criação e configuração de contas de softwares:

Em redes heterogêneas, os pacotes de software devem ser instalados de forma que estes tenham sua própria conta (de uma forma similar aos usuários comuns) e, consequentemente, seu próprio uid. Normalmente as contas dos pacotes pertencem a um mesmo grupo, o grupo local do Unix. Para cada pacote instalado existe um netgroup contendo o nome dos usuários que podem ter acesso ao mesmo. Para tanto é necessário que apenas que o usuário execute o comando nsu fornecendo o “login” correspondente ao pacote em questão, nenhuma password é solicitada. Por uma questão de segurança do sistema, cada arquivo do pacote deve ser criado com o dono correspondente. Os sistemas devem, em geral, prover uma verificação deste requisito e deletar qualquer arquivo cujo dono não possa ser identificado.

Cada pacote tem seu próprio diretório home ( /home/<pacote> ) onde são mantidos, além dos arquivos fonte (quando fornecidos), arquivos relacionados com documentação, opções de compilação, redirecionamento de e-mails, entre outros.

No caso particular do sistema analisado (Universidade de Edinburgo), são mantidos os os seguintes arquivos na conta de cada pacote de software:

• README: contém informações sobre o pacote instalado. Este arquivo deve ser copiado em um diretório que contém informação sobre todos os pacotes instalados no sistema
• .mailfilter: arquivo responsável pelo redirecionamento dos e-mails enviados para o pacote. Estes e-mails devem ser entregues aos responsáveis pelo software.
• .support: contém uma única letra maiúscula que é atribuída ao pacote de acordo com o suporte que este deve receber. Neste sistema, os softwares podem ser classificados de acordo com o nível de suporte necessário em 4 níveis classificados de A a D conforme a descrição abaixo:
• A: pacotes que compõem o ambiente padrão e que, portanto, devem ser suportados por qualquer das arquiteturas existentes na rede. Todo suporte possível a nível de atualização, correção de erros e documentação é fornecido.
• B: pacotes que normalmente funcionam bem. Não é garantido suporte a nível de atualização nem portabilidade para todas as arquiteturas da rede. É fornecido suporte adequado a nível de correção de erros, contudo estes pacotes tem menor prioridade em relação aos classificados como A.
• C: pacotes que se encontram freqüentemente operacionais. Os erros apresentados devem ser solucionados pelos próprios usuários dos pacotes, sendo-lhes fornecido algum apoio.
• D: pacotes que estão disponíveis, mas sem nenhuma garantia ou suporte.

Existem várias vantagens nesta técnica de utilização de uids separados para cada pacote de software instalado, tais como:

• Facilidade de localização dos arquivos que correspondem a um determinado pacote de software;
• Facilidade de obtenção de sumários relatando o espaço ocupado por cada pacote;
• Facilidade na manutenção de uma documentação atualizada dos pacotes instalados na rede a partir dos arquivos contidos nos diretórios home dos pacotes;
• Facilidade no redirecionamento de e-mails para os responsáveis pelo respectivo software;
• Facilidade na organização do sistema como um todo (a partir dos arquivos que indicam opções de compilação, etc.).

Quando se possui várias versões de um mesmo software instaladas é comum ter-se o cuidado de criar um subdiretório do diretório home para cada uma das versões. Outra medida indicada é criação de um subdiretório para conter a versão original do software quando este precisar sofrer modificações para adequação ao ambiente local. Este tipo de providência permite que o software possa ser facilmente distribuído para outros sites.

2.2 Escolha e configuração de diretórios:

Para que o sistema funcione bem e de uma maneira estruturada, visando manter a transparência para os usuários, é necessário que os arquivos que compõem os pacotes de software estejam adequadamente organizados em diretórios. Normalmente os softwares locais podem ser acessados a partir de subdiretórios de /usr/local. Estes subdiretórios contêm, em geral, apenas links para os arquivos que encontrar-se-ão armazenados em diversos servidores. Os principais diretórios normalmente envolvidos na instalação de softwares são:

1. /usr/local/bin: Normalmente contém os softwares que os usuários, em geral, podem acessar.
2. /usr/local/etc: Contém programas relacionados com a manutenção do sistema.
3. /usr/local/lib: Contém outros programas dependentes de arquitetura.
4. /usr/local/man: Utilizado para guardar as páginas dos manuais.
5. /usr/local/include: Contém arquivos de cabeçalho.

Como se pode observar, a estrutura do sistema de arquivo utilizado para conter os softwares locais, /usr/local, é bastante similar a estrutura do sistema de arquivos /usr, padrão do Unix.

2.3 Compilação:

Em um sistema isolado, pacotes de software normalmente são compilados diretamente no diretorio de fontes. Essa abordagem se mostra insatisfatória em sistemas de redes heterogeneas pelos seguintes fatores:

• Se o administrador configurar backups periodicos dos fontes dos softs instalados, esses backups copiarão os arquivos binários especificos de uma arquitetura, aumentando a quantidade de espaço necessario para o backup.
• A maioria dos pacotes não fornece suporte a compilação de mais de uma versão do soft o que pode levar a confitos de aquivos objetos de arquiteturas diferentes.
• É util ter a versão original do soft sem os arquivos objetos a disposição no caso de erros.

Por isso é recomendável, antes de se instalar um software, criar uma heirarquia de diretorios que possuirão armazenarão os binarios de cada soft organizados por arquitetura e versão.

2.4 Instalação e manutenção de servidores:

Em geral, o processo de instalação deve iniciar-se pela escolha de um servidor master para cada software a ser instalado. O servidor master será aquele que irá conter a cópia “primitiva” do software para cada uma das diferentes arquiteturas que compõem a rede. Além deste servidor master, que é único, os softwares podem ter servidores slaves, principalmente se são softwares bastante utilizados. Estes servidores slaves contêm cópias dos programas contidos no servidor master. Os servidores slaves em geral são utilizados para se conseguir uma melhor distribuição de carga na rede, além de prover um aumento na confiabilidade do sistema.

Após o processo de compilação do software, a instalação pode ser concluída copiando-se os arquivos gerados, para áreas adequadas naquele que será o servidor master do software. Normalmente os servidores que estão configurados como slaves são responsáveis pela busca das cópias contidas no servidor master, tarefa esta realizada geralmente no período da noite.

Após a conclusão do processo de instalação, os clientes estarão aptos a montar seus diretórios /usr/local a partir de um servidor próximo.

Algumas considerações importantes ainda devem ser feitas:

• Devido ao período normal de atualização dos slaves ser durante a noite, alterações no servidor master só serão percebidas por toda a rede no dia seguinte, o que acarreta problemas temporários na homogeneidade do sistema
• Normalmente, slaves vão conter arquivos de mais de um master, de forma que é necessário que se garanta que atualizações de arquivos por um servidor master não terão influência nos arquivos que não lhe dizem respeito
• Vários softwares, tais como daemons e shells, podem estar rodando durante a atualização dos servidores slaves. Para que estes programas não deixem subitamente de funcionar durante este período, estes programas devem ser anexados a uma lista de kepfiles, que são arquivos que não terão seus binários apagados imediatamente quando da atualização dos slaves
• É importante que se possa manter um arquivo de log de todos os arquivos atualizados de modo a facilitar a manutenção do sistema e prover aos usuários uma lista de todos os arquivos(softwares) que foram recentemente atualizados.

3- Referências:

Paul Anderson, Managing Program Binaries In a Heterogeneous UNIX Network, Department of Computer Science, University of Edinburgu, October 1991.

Paul Anderson, A Guide to the local UNIX Directory Hierarchy, Department of Computer Science, University of Edinburgu, September1996.

Paul Anderson, Installing Software Packages on the Computer Science Department UNIX Network, Department of Computer Science, University of Edinburgu, October 1996.