Danise Víctor Xavier

Departamento de Informática

Universidade Federal de Pernambuco

e-mail: dvx@di.ufpe.br

Recife, 09 de maio de 1996

O NFS (Network File System) é um sistema de arquivo distribuído que provê acesso transparente a discos remotos. Este serviço permite centralizar a administração dos discos, assim como o NIS permite a administração centralizada das informações dos usuários e dos hosts.

Ao invés de duplicação de diretórios comuns como o /usr/local em cada sistema, o NFS oferece compartilhamento de uma única cópia do diretório entre todos os sistemas da rede.

Na visão do usuário, a utilização do NFS significa não ter que se logar em cada sistema para acessar os arquivos. Eles não precisam utilizar o comando rcp ou fitas para transferir arquivos entre sistemas locais. O NFS garante que os arquivos necessários aos usuários são acessíveis de qualquer host da rede.

O NFS é construído sobre um protocolo RPC e impõe o relacionamento cliente/servidor aos hosts que o utilizam. Um servidor NFS é um host que possui um ou mais sistemas de arquivos e os torna disponível pela rede. O cliente NFS monta estes sistemas de arquivos de um ou mais servidores.

Existem dois aspectos para a administração de sistemas utilizar o NFS: primeiramente escolher um esquema de nomes para os sistemas de arquivos e montá-lo. O objetivo do esquema de nomes é utilizar a transparência dos dados de modo amplo. E segundo, configurar os servidores e clientes NFS. Um ambiente com muitos servidores NFS e centenas de clientes podem rapidamente se tornar de complexo gerenciamento.

Configurar o NFS envolve a instalação dos clientes e servidores, a inicialização dos daemons que tratam do protocolo RPC do NFS, e os daemons adicionais que auxiliam em serviços como segurança de arquivos, e por fim a exportação dos sistemas de arquivos dos servidores NFS e montagem deles nos clientes NFS.

No cliente NFS, se faz necessário executar os daemons biod, rpc.lockd e rpc.statd. Eles são geralmente inicializados a partir de scripts de inicialização.

• biod - executa operações de E/S para os clientes NFS, executa também algumas otimizações de leitura e escrita.

• rpc.lockd e rpc.statd - tratam de file locking e recuperação de lock no cliente.

Os serviços no servidor NFS são inicializados a partir dos daemons nfsd e rpc.mountd, como também os daemons que tratam de file locking utilizados nos clientes NFS.

• nfsd - aceita as requisições RPC e as executa no servidor.

• rpc.mountd - trata das requisições de mount dos clientes.

Um servidor NFS mantêm uma lista dos sistemas de arquivos correntemente exportados e as correspondentes restrições de acesso, em um arquivo chamado /etc/exports. A cada solicitação de montagem de sistema de arquivos, é realizada uma pesquisa nesta tabela.

Quando da inicialização de um servidor de arquivos, é verificada a existência do /etc/exports e então, é executado o comando exportfs para tornar os sistemas de arquivos disponíveis aos clientes.

Uma amostra de um arquivo /etc/exports seria:

Na primeira coluna estão relacionados os sistemas de arquivos a serem exportados. Depois segue o conjunto de opções de acesso, onde:

• ro - Limita o acesso ao sistema de arquivo para apenas leitura. Pelo fato do servidor NFS não poder determinar qual a opção foi especificada pelo cliente ao montar o sistema de arquivo, esta fica sendo a opção default. Se o cliente houver montado um sistema de arquivo com opção de leitura e escrita e o servidor determinar a exportação do mesmo como sendo ro, então qualquer tentativa de escrita neste sistema de arquivo irá causar um erro.

• rw=host:host - Limita o conjunto de hosts que podem escrever no sistema de arquivo. Se for omitido o nome do host, qualquer cliente NFS pode escrever neste sistema de arquivo.

• access=host:host - Permite acesso ao sistema de arquivo apenas aos hosts definidos em host.

• anon=uid - Possibilita aos usuários anônimos acessarem o sistema de arquivo, realizando o mapeamento deles para o uid especificado. Usuários anônimos são aqueles que não apresentam credenciais válidas em suas requisições NFS.

• root=host:host - Garante acesso de superusuário ao hosts definidos.

Para os clientes acessarem os sistemas de arquivos dos servidores, estes devem seguir algumas regras de exportação:

• Qualquer sistema de arquivo, ou subconjunto de um sistema de arquivo, pode ser exportado de um servidor;

• Não é possível exportar qualquer subdiretório de um sistema de arquivo já exportado, a menos que o subdiretório esteja em um dispositivo físico diferente. Por exemplo, o subdiretório /usr/local/bin pode ser exportado a partir do mesmo servidor que está exportando /usr/local, se /usr/local/bin estiver localizado em outro disco físico;

• Não é possível exportar qualquer diretório "pai" de um sistema de arquivo já exportado, a menos que ele esteja em um dispositivo físico diferente;

• É permitido exportar apenas sistemas de arquivos locais.

Uma forma de verificar a validade dos subdiretórios exportados é utilizar o comando df para determinar em qual sistema de arquivo local o diretório corrente está localizado. Se não for encontrado o diretório "pai", nem seus subdiretórios, então eles estão fisicamente separados e é possível exportar ambos.

Com o NFS, é útil exportar um subdiretório de um sistema de arquivo, se este último como um todo contêm subdiretórios com nomes que possam confundir os usuários, ou se o sistema de arquivo contêm várias árvores de diretórios paralelas das quais apenas uma é utilizada pelo usuário.

Os clientes NFS podem montar qualquer sistema de arquivos, ou parte deles, desde que tenham sido exportados pelo servidor NFS. Um sistema de arquivo é montado em um diretório no cliente NFS, chamado de mount point. Quando o mount point é a raiz de outro sistema de arquivo, tudo que estiver abaixo dele se tornará obscuro.

Os sistemas de arquivos podem estar relacionados no arquivo /etc/fstab, ou podem ser montados diretamente através do comando mount. Adicionar entradas ao /etc/fstab é a maneira mais comum de montar sistemas de arquivos via NFS. Uma vez que uma entrada está no arquivo /etc/fstab, o cliente monta este sistema de arquivos a cada reinicialização.

Um trecho de um arquivo /etc/fstab é mostrado a seguir:

As opções mais comuns da montagem de sistemas de arquivos são:

• server:filesystem - Especificação do nome do dispositivo. filesystem é o nome completo do sistema de arquivo no servidor.

• nfs - Tipo do sistema de arquivo. Para sistemas de arquivos locais é utilizado o tipo 4.2.

• rw - Monta um sistema de arquivo leitura-escrita; é a opção default.

• ro - Uma vez especificado, monta o sistema de arquivo somente leitura.

• bg - Recupera uma falha do mount em background, permitindo que o processo mount em foreground continue.

• hard - É a opção default, significando que as operações sobre os sistemas de arquivos são repetidas até que o servidor as reconheça.

• soft - Uma chamada RPC NFS retorna um erro de timeout se as operações falharem o número de vezes especificado pela opção retrans.

• retrans - Determina o número de vezes que uma requisição RPC será repetida antes de ser retornado um erro de timeout em um sistema de arquivo montado com a opção soft.

• timeo - Varia o período do timeout e é dado em décimos de segundos.

• intr - Normalmente, operações NFS não são interrompidas e continuam até um erro RPC ocorrer ou ser completada com sucesso. Com a opção intr, o usuário pode interromper uma chamada RPC NFS e forçar o envio de uma mensagem de erro.

Algumas vezes é necessário montar os sistemas de arquivos diretamente da linha de comando, ou temporariamente enquanto são copiados arquivos neles. O comando mount permite executar a montagem de um sistema de arquivo que se manterá ativo até ser explicitamente desmontado usando o comando umount, ou até o cliente NFS ser reinicializado.

Da linha de comando, o mount adota uma sintaxe similar àquela empregada no arquivo /etc/fstab. O mount assume que o tipo do sistema de arquivo é nfs se o nome do host for definido na especificação do dispositivo. Por exemplo:

O nome do sistema de arquivo no servidor deve ser um caminho absoluto (iniciando com /), mas não precisa ser exatamente o nome do sistema de arquivo exportado. A única restrição no nome do sistema de arquivo do servidor é que ele deve conter um prefixo válido no servidor que exportou o sistema de arquivo. Por exemplo, tendo sido exportado o sistema de arquivo /home/ono, é possível montar a seguinte entrada do arquivo /etc/fstab:

4.1. Montagem em background

Quando um cliente não pode montar um sistema de arquivo durante o tempo de execução de uma RPC, ele repete esta operação por um intervalo de tempo especificado no contador retry. Se a opção bg é utilizada, o mount inicia outro processo e continua tentando o mount anterior em background. Se a opção bg não estiver ativa, o mount bloqueia e fica aguardando o servidor de arquivos remoto se recuperar, ou até que o contador retry seja alcançado.

Não é possível manter em background a montagem de sistemas de arquivos críticos como / ou /usr. Se eles precisam estar em execução no sistema, devem ser montados em foreground. O uso de montagem de sistemas de arquivos em background, permite que a rede se recupere mais facilmente dos problemas com falta de energia, por exemplo.

Quando dois servidores são clientes um do outro, a opção bg deve ser utilizada no arquivo /etc/fstab de no mínimo um dos servidores. Quando ambos os servidores inicializam ao mesmo tempo, por causa de uma queda de energia, por exemplo, um tenta montar os sistemas de arquivos do outro antes deles terem sido exportados e antes mesmo do NFS está ativo. Se eles executam a montagem em foreground ocorrerá um deadlock, pois um ficará esperando pelo outro. Utilizando a opção bg, a montagem é completada com sucesso.

4.2. Montagem hard e soft

As opção de montagem hard e soft determinam como um cliente deve se comportar quando o servidor está excessivamente carregado por um longo período, ou quando ele fica down. Por default, todos os sistemas de arquivos NFS são montados hard, o que significa que uma chamada RPC expirada será realizada indefinidamente até uma resposta ser recebida do servidor.

Se um servidor NFS se torna down, os clientes que utilizam seus sistemas de arquivos também irão ficar down sempre que fizerem referência a estes sistemas de arquivos antes do servidor se recuperar. Usando a opção intr em conjunto a opção hard, o usuário poderá interromper uma chamada do sistema que está aguardando uma requisição feita ao servidor down.

Quando um sistema de arquivo NFS é montado com a opção soft, repetidas falhas de chamadas RPC irão resultar em falhas nas operações NFS. Um sistema de arquivo que será escrito ou que contenha executáveis não deverá ser montado com a opção soft, pois o NFS garante consistência dos dados após uma queda do servidor, apenas se os sistemas de arquivos forem montados pelos clientes com a opção hard.

Eles podem ser usados para definir um sistema de arquivo arbitrariamente, dando ao administrador de sistema liberdade para organizar os sistemas de arquivos e os nomes dos caminhos do modo mais conveniente. Quando usados de forma errônea, os links simbólicos produzem resultados inesperados e indesejados, além de reduzir a performance e não mais localizar arquivos e diretórios.

Links simbólicos diferem de links hard principalmente pelo seguinte fator: os links hard duplicam as entradas dos diretórios, enquanto que links simbólicos são novas entradas de diretórios de um tipo especial. Usar um link hard para um arquivo não é diferente de usar o arquivo original, mas fazer referência a um link simbólico requer ler o link para identificar onde ele aponta e então, acessar aquele arquivo ou diretório. É possível criar um loop de links simbólicos, mas as rotinas do kernel que lêem os links e constróem os caminhos eventualmente retornam um erro quando muitos links compõem um único caminho.

5.1. Links simbólicos com NFS

Quando um cliente NFS executa uma função stat( ) de uma entrada do diretório e encontra um link simbólico, ele aciona uma chamada RPC para ler o link, no servidor, e determinar para onde ele aponta. Isto é equivalente a realizar uma chamada de sistema local readlink( ) para examinar o conteúdo de um link simbólico. O servidor retorna o caminho completo que é interpretado no cliente, e não no servidor.

O caminho completo pode apontar para um diretório que o cliente tenha montado, ou ele pode não fazer sentido para o cliente. Se o link realizado no servidor apontar para um sistema de arquivo não exportado, irão surgir problemas e confusões ao resolver o link. Se ele apontar para um arquivo ou diretório válido no cliente, os resultados serão imprevisíveis e algumas vezes indesejáveis. Se o link aponta para algum ponto não existente no cliente, qualquer tentativa de acesso a ele irá produzir um erro.

5.2. Caminhos absolutos e caminhos relativos

Links simbólicos podem apontar para um caminho absoluto, iniciando com /, ou um caminho relativo, apontando para outro link. Links simbólicos relativos são resolvidos relativos ao local onde o link aparece no sistema de arquivo do cliente NFS, não no do servidor, desta forma é possível links relativos apontarem para um arquivo ou diretório não existente no cliente.

Por exemplo, considerando existir no servidor o seguinte diretório:

Se for montado apenas o sistema de arquivo /usr/local/bin, não será possível utilizar qualquer executável, a menos que eles existam no diretório /usr/local/bin.mips localmente.

A utilização de links simbólicos reduz o número de diretórios em um caminho, é benéfico apenas se os usuários não tentarem utilizar o comando cd de um link para outro. Por exemplo:

Os caminhos relativos não são relativos ao diretório do link.

Portanto, links simbólicos nem sempre se constituem a melhor solução para os problemas de nomes de caminhos longos.

5.3. Montando e exportando links

Links simbólicos têm um efeito estranho em sistemas de arquivos montados e exportados. Um regra geral a ser lembrada é que as operações em sistemas de arquivos se aplicam somente ao alvo do link, não ao próprio link. O link simbólico é visto apenas como um ponteiro para o verdadeiro sistema de arquivo que irá sofrer a operação.

Ao montar um sistema de arquivo sob um link simbólico, a montagem real ocorre sobre o diretório apontado pelo link. Por exemplo:

É o mesmo que executar esta outra seqüência de comandos:

Para exportar um link simbólico de um servidor, as regras são similares a montagem dos links. O sistema de arquivo, ou subárvore de um sistema de arquivo, que é realmente exportado é aquele apontado pelo link simbólico. Se o diretório pai do alvo do link, ou uma subárvore deste, já houver sido exportado, qualquer tentativa de exportar o link irá falhar.

Montar um link de um servidor não é o mesmo que montar um sistema de arquivo contendo um link. Este último significa que existe um link em algum lugar no sistema de arquivo montado usando NFS. O primeiro implica que o caminho do servidor usado para localizar o sistema de arquivo remoto é um link e direciona a montagem para algum outro local. Por exemplo, existindo um link simbólico do /usr/man para o /usr/share/man, o comando:

realiza o mesmo que o comando:

A figura 5.3.1 ilustra este exemplo:

Um cuidado deve ser tomado quando o link simbólico e o diretório para o qual ele aponta estão fisicamente em sistemas de arquivos diferentes. É comum que seja exportado apenas o sistema de arquivo do link, e não o sistema de arquivo alvo.

Um esquema de nomes eficiente e simples torna os sistemas de arquivos bem organizados e facilita a sua utilização. O NFS provê um mecanismo para tornar os sistemas de arquivos distribuídos de modo transparente ao usuário, mas ele não apresenta regras de herança para criar uma hierarquia de sistemas de arquivos fácil de gerenciar. Existem poucas regras globais, e cada rede adota convenções baseada no número de servidores, tipos de arquivos tratados pelos servidores, e outros requisitos peculiares.

O administrador de sistemas deverá primeiramente decidir como os vários servidores de arquivos NFS se encaixam junto ao cliente antes de atribuir nomes aos sistemas de arquivos e adequá-los aos softwares e usuários. Algumas sugestões estão relacionadas a seguir:

• Utilizar /home/hostname para os diretórios home dos usuários. O hostname indica o servidor onde os arquivos estão localizados. Isto parece contrariar os objetivos de transparência do NFS, mas torna a administração da rede e a geração do arquivo /etc/fstab mais facilitada.

• Uma alternativa seria utilizar o esquema de nomes mais simples, /home/username, para montar cada diretório home do usuário. Este esquema facilita a comunicação com os servidores que têm vários sistemas de arquivos de diretórios home, pois eles não têm que criar nomes para atribuir ao modelo /home/hostname. A desvantagem deste esquema é que ele requer um arquivo /etc/fstab muito grande, com uma entrada para cada diretório home do usuário.

• Utilizar os mesmos caminhos no cliente e no servidor, de forma que seja fácil encontrar e solucionar problemas no servidor.

• Separar as ferramentas em grupos de subdiretórios por função. Por exemplo, /tools/epubs para composição de páginas e publicação de softwares, e /tools/cae para ferramentas de engenharia. Se o diretório crescer muito ao ponto de precisar se tornar um sistema de arquivo próprio, é possível mover todo o subdiretório para um novo servidor e preservar o mesmo esquema de nomes, montando ambos os subdiretórios nos clientes NFS:

6.1. Esquema de nomes para os binários

É comum encontrarmos ambientes de redes com diferentes tipos de estações de trabalho, são ambiente heterogêneos. Os executáveis podem ser construídos a partir dos mesmos arquivos fonte, mas é necessário binários diferentes para cada arquitetura de máquina.

Implementar um esquema de nomes para o /usr/local/bin neutro às várias arquiteturas é um grande desafio ao administrador de sistemas de uma rede heterogênea. O ideal seria manter um diretório bin para cada arquitetura, e quando um usuário visualizar o diretório /usr/local/bin de qualquer máquina, ele deveria encontrar os executáveis próprios da arquitetura local.

Uma solução seria atribuir nomes aos diretórios de binários individualmente com o tipo da máquina como um sufixo e então montar aquele que for apropriado no /usr/local/bin. Por exemplo:

Este esquema é suficiente se existem apenas binários naquele diretório, mas muitas vezes são acrescentados páginas de manuais, código fonte, e outros arquivos ASCII que são compartilhados através das diferentes arquiteturas. Não há necessidade de manter múltiplas cópias destes arquivos. Sendo assim, é realizado dois mounts do mesmo sistema de arquivo. Por exemplo:

O esquema de nomes utilizado no DI-UFPE, tanto para os arquivos binários, como para os diretórios home dos usuários, serão abordados junto ao seminário sobre o BSD-Automounter.

7.1. Definição

É uma implementação cliente do protocolo NFS para microcomputadores executando o sistema operacional MS-DOS. As máquinas que utilizam o PC/NFS podem montar sistemas de arquivos NFS como discos lógicos, e usá-los como grandes discos virtuais DOS.

7.2. Configuração

O PC/NFS vem com vários módulos: uma biblioteca RPC e XDR, utilitários DOS para montar os discos e criar credenciais de usuários no estilo UNIX, uma implementação NIS, um conjunto de drives de protocolos de rede TCP, UDP e IP, e uma interface de rede adicional.

Para executar o PC/NFS, devem estar instalados todos os componentes do PC, como drivers e scripts de inicialização, e então instalar um novo daemon do servidor RPC no servidor NFS para tratar de requisições de impressão.

O PC/NFS tem um programa da configuração bastante robusto, nfsconf, que conduz toda a instalação inicial e alterações subsequentes com uma simples interface orientada a menus.

O PC/NFS inclui uma implementação do cliente NIS, de modo que ele pode utilizar os mapas NIS passwd, hosts, rpc, services, netgroup, ethers e networks. Se o NIS não está sendo executado nas máquinas UNIX, ou se ele não será utilizado nos clientes PC, os arquivos locais deverão ser editados com a configuração específica ao PC. Estes arquivos deverão ficar localizados no diretório /NFS.

A maior parte das configurações do PC/NFS ocorre no arquivo NETWORK.BAT, que é ativado no AUTOEXEC.BAT no momento da inicialização. O arquivo DRIVES.BAT contem comandos para montar sistemas de arquivos no PC, de modo similar ao arquivo /etc/fstab.

7.2.1. Inicializando o PC/NFS

• O primeiro passo é definir um domínio NIS, através do comando net ypdomain:

Se o domínio NIS é maior que 14 caracteres, versões mais antigas do PC/NFS não serão capazes de identificá-lo. Deve-se então criar um alias para o domínio NIS nos servidores NIS, em [1] capítulo 3.

• Com um domínio NIS válido, o PC precisa encontrar um servidor para os mapas do domínio. Isto é feito através do comando net ypset:

O PC forma uma ligação estática com o servidor nishost ou retorna um erro se o host não for um servidor NIS.

net ypset *

O PC envia um broadcast para os servidores no seu domínio.

Para manter as permissões dos arquivos NFS no estilo UNIX, PC/NFS utiliza uma máquina UNIX que verifica as credenciais dos usuários em relação as permissões dos arquivos acessados via PC/NFS. Este host é chamado de servidor e autenticação. Ele retorna um daemon, chamado pcnfs, que executa autenticação dos usuários e trata de requisições de impressão. Por default o servidor NIS e o de autenticação são os mesmos, mas podem ter suas funções separadas pela especificação de um servidor de autenticação diferente no arquivo NETWORK.BAT. Por exemplo:

O servidor NIS será utilizado para localizar informações de usuário e nomes de hosts, mas todas as autenticações das credenciais dos usuários serão realizadas pelo servidor de autenticações. Apesar de não ter que ser o servidor NIS, o servidor de autenticações deve ser o servidor NFS se ele for utilizado para serviços de suporte a impressão.

• O último passo, é inicializar o redirecionador da rede. Quando o redirecionador está em execução o PC/NFS está ativo. O comando net start rdr inicializa o redirecionador, e é normalmente o último comando do arquivo NETWORK.BAT:

O redirecionador da rede é o "coração" das operações PC/NFS. Ele intercepta as requisições que irão normalmente para o sistemas de E/S do DOS e as empacota em requisições RPC destinadas ao servidor NFS adequado. O redirecionador é similar ao daemon biod nos clientes NFS, mas ele trata de todos as operações de arquivos, não apenas aquelas que requerem transferência de blocos de dados.

Se o NIS não for utilizado nas máquinas UNIX, ou nos clientes PC, configure o nome do host explicitamente através do comando net start, por exemplo:

net start rdr pchost *

7.2.2. Configurando o servidor

No lado do UNIX existe um daemon servidor PC/NFS que é utilizado em adição aos daemons convencionais dos servidores NIS e NFS. O daemon pcnfs deve estar sendo executado em uma máquina que seja um servidor NFS, isto porque ele usa o NFS para reunir os arquivos de impressão dos clientes PC. O pcnfs é inicializado no momento do boot no servidor UNIX, normalmente a partir do script /etc/rc.local:

Uma vez estando em execução o redirecionador e os daemons servidores, o PC/NFS pode ser utilizado para montar sistemas de arquivos NFS como discos virtuais. Para um usuário UNIX, os sistemas de arquivos do PC são vistos como algo muito estranho, pelo fato dos discos serem organizados por nome de volumes, ao invés de uma árvore de nomes de caminhos. Além disso, as convenções dos nomes dos arquivos, as permissões e a estrutura dos arquivos são diferentes entre os dois sistemas operacionais.

O comando net use atribui um disco lógico ao um sistema de arquivo remoto:

O nome do servidor é dado após duplas barras invertidas, e o caminho completo do sistema de arquivo no servidor segue as convenções de nomes normais ao DOS. Deve-se ter atenção em não tentar montar um sistema de arquivo no topo de um drive lógico existente. Após a montagem, o sistema de arquivo pode ser tratado como um drive normal no DOS, copiando ou abrindo arquivos como se fossem locais ao PC.

Por default, aos usuários dos PC’s são dadas as permissões de usuário anônimo, nobody, o que geralmente significa que os usuários do PC podem acessar os arquivos com permissão apropriada a todos. Para restringir os privilégios, um usuário PC deverá se logar no servidor de autenticação usando o comando net name:

Password: ou Username: stern

Password:

O PC/NFS executa uma verificação da senha e do nome do usuário como o login do UNIX no servidor de autenticação, utilizando informações de usuários recuperadas do servidor NIS do PC/NFS.

Mesmo com as credenciais no estilo UNIX, não existem mecanismos no DOS para executar a verificação das permissões dos arquivos. Este problema é resolvido através do servidor de autenticação, uma vez que ele deverá verificar as credenciais dos usuários em relação aos atributos dos arquivos. Para qualquer acesso a um arquivo é realizada uma verificação das permissões.

Os nomes dos arquivos do UNIX contêm 14 (quatorze) caracteres, e em algumas versões são até maiores. Eles também podem conter um variedade de caracteres especiais e sinais de pontuação. Os nomes dos arquivos DOS, por outro lado, são compostos por 8 (oito) caracteres com os 3 (três) caracteres opcionais que é a extensão, são apenas maiúsculos e não podem incluir pontuação como ponto final (.). Todos os arquivos DOS são válidos na sintaxe UNIX, mas o contrário não é verdadeiro.

O PC/NFS adota algumas convenções para converter nomes de arquivos UNIX em arquivos DOS. O mapeamento é realizado na máquina PC e os arquivos UNIX não sofrem nenhuma alteração física de seus nomes. Os mapeamentos mais recentes são armazenados no PC de forma que o cliente não tenha que continuamente realizar conversões.

Arquivos UNIX com quaisquer das combinações de caracteres abaixo, são convertidos para arquivos DOS válidos:

• iniciando com pontos;

• extensão DOS ilegal;

• prefixos maiores que 8 (oito) caracteres;

• múltiplos pontos;

• nomes que não são únicos nos primeiros 8 (oito) caracteres;

• letras maiúsculas.

Os regras de mapeamento são relacionadas na tabela abaixo:

Se o símbolo (~) causar confusão com outras aplicações DOS que utilizem este caractere, o esquema de mapeamento pode ser modificado para outro caractere no arquivo CONFIG.SYS, por exemplo modificando para o caractere ( _ ):

DEVICE=C:\NFS\PCNFS.SYS /C_

O DOS não tem suporte para links simbólicos, mas os clientes PC/NFS podem seguir links simbólicos com algumas limitações.

O mapeamento do nome do arquivo UNIX para DOS impõe limitações nos links simbólicos utilizados no PC/NFS. Se qualquer componente no alvo do link requerer um mapeamento do nome do arquivo UNIX para DOS, então o PC/NFS não será capaz de seguir o link. Após o mapeamento ser executado, a visão do cliente do caminho obtido e do caminho real, não irão combinar. Links simbólicos podem ser seguidos pelo cliente PC/NFS apenas se o caminho alvo do link seguir as convenções dos nomes de arquivos DOS.

Além das diferenças entre os nomes e as permissões, o DOS e o UNIX diferem em suas convenções de final de linha e final de arquivo. O PC/NFS inclui os utilitários dos2unix e unix2dos para converter entre os dois formatos. Quando converte para o formato DOS, os caracteres UNIX de final de linha (\n) são convertidos para newlines e carriage returns, e um caractere DOS de final de arquivo (CTRL-Z) é adicionado. No outro sentido, carriages returns e marcas de final de arquivo são retiradas do arquivo.

7.4. Serviços de impressão

PC/NFS permite que os usuários acessem uma impressora acoplada a um host UNIX, a partir de um PC, pelo redirecionamento da saída de impressão DOS para um host PC/NFS.

O comando net use, utilizado para definir discos remotos, também define impressoras remotas. O nome do host de impressão é precedido por duplas barras invertidas, e o nome da impressora UNIX é usado como caminho do servidor:

O servidor de impressão deve estar executando o pcnfsd, e ele deve conter uma definição para a impressora no seu arquivo /etc/printcap.

As funções PC/NFS de autenticação e impressão são executadas pelas mesmas máquinas: ambos os serviços são tratados pelo daemon pcnfsd que é executado no servidor de autenticação.

Existem duas classes de saídas de impressão do PC/NFS: arquivos completos e saídas de aplicações que escrevem em dispositivo de impressão DOS. Para enviar um arquivo para a impressora , é utilizado o mecanismo de impressão normal do DOS, e o PC/NFS redireciona a saída para LPT1: para utilizar a impressora UNIX. Ou então, utilizando o comando net print.

Redirecionar a saída da impressão de uma aplicação é um pouco mais complicado. O mecanismo de impressão do DOS simplesmente envia um stream de saída para um dispositivo, sem qualquer spooling. O DOS apenas executa uma tarefa por vez, assim, não há chance de duas tarefas tentarem imprimir ao mesmo tempo. O sistema de impressão de linha do UNIX, entretanto, realiza o spool das saídas de múltiplos usuários em múltiplos hosts. Ele força o acesso a impressora de uma única tarefa por vez através de filas de jobs. Para implementar este esquema o UNIX precisa conhecer onde começa e onde termina o arquivo a ser impresso. Isto se constitui um problema quando o UNIX tenta coletar uma saída de impressão de uma aplicação DOS, pois não há uma indicação clara do final de um arquivo de impressão.

O PC/NFS resolve este problema, através do spooling de arquivos de impressão no PC até a aplicação que conduziu a impressão não mais acessar o dispositivo de impressão por cinco minutos ou até a aplicação encerrar a impressão.

7.5. Administração da rede PC/NFS

O conjunto de ferramentas de administração de uma rede PC/NFS permite serem definidas rotas para acessar servidores de arquivos UNIX remotos, visualizar estatísticas de PC/NFS, e configurar os drivers de rede para otimizar a performance dos clientes PC/NFS.

Para definir uma rota default no arquivo NETWORK.BAT o comando net route deve ser utilizado:

Para depurar algum problema ocorrido em uma rede PC/NFS serão utilizados os mesmos procedimentos dos clientes NFS do UNIX. O PC/NFS inclui várias ferramentas de diagnósticos que apresentam função e uso similar àquelas do UNIX. Algumas delas são:

• netstat [-s] [-i] - Apresenta estatísticas sobre a interface de rede (opção -i) e sobre o número de pacotes de cada protocolo tratados pelo host (opção -s, que é a default).

• arp - Mostra a tabela ARP do PC. Se houver problemas de comunicação com os servidores, deve ser garantida e existência de no mínimo uma entrada válida na tabela ARP.

• nfsstat - Imprime estatísticas do NFS e de chamadas RPC do cliente, mostrando o número de chamadas a cada procedimento RPC e o número de erros registrados.

• nsfping host - Executa uma rpcinfo para o host, e verifica se ele está executando o daemon de servidor. Pode também ser utilizado em arquivos de lote para testar se o servidor de arquivos está disponível antes de utilizar o comando net use para montar um sistema de arquivo a partir deste.

1. Hal Stern - Managing NFS and NIS - O’Reilly & Associates, Inc. - 1991.
1. Evi Nemeth, Garth Snyder, Scott Seebass, Trent R. Hein - UNIX System Administration Handbook - Prentice Hall PTR - 1995.