Utilização e Operação do NFS

PC/NFS 

1. Introdução

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.

2 . Configurando o NFS

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.

3 . Exportando Sistemas de Arquivos

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:

/home/users

/usr/local -rw=corvette

/usr/tools -ro,access=bitatron:corvette:vacation

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.
 

4 . Montando Sistemas de Arquivos

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:

ono:/home/ono /home/ono nfs rw,bg,hard 0 0

onaga:/home/onaga /home/onaga nfs rw,bg,hard 0 0

wahoo:/var/spool/mail /var/spool/mail nfs rw,bg,hard 0 0

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:

# mount ono:/home/ono /home/ono -o rw,bg,hard

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:

ono:/home/ono/stern /home/ono/stern nfs rw,bg,hard 0 0

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.

5 . Link Simbólico

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:

% cd /usr/local/bin

% ls -l

total 1
lrwxrwxrwx 1 root 16 Jun 8 1990 a2ps->../bin.mips/a2ps

lrwxrwxrwx 1 root 12 Jun 8 1990 mp->../bin.mips/mp

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:

# ln -s /home/minnow/fred /u/fred

# ln -s /home/alewife/lucy /u/lucy

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

% cd /u/fred

% cd ../lucy

../lucy: No such file or directory

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:

# mkdir /home/hal

# ls -s /home/hal /usr/hal

# mount bitatron:/home/hal /usr/hal

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

# mkdir /home/hal

# mount bitatron:/home/hal /home/hal

# ls -s /home/hal /usr/hal

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:

# mount bitatron:/usr/share/man /mnt

realiza o mesmo que o comando:

# mount bitatron:/usr/man /mnt

A figura 5.3.1 ilustra este exemplo:

fig. 5.3.1. Montagem de um link simbólico

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.
 

6 . Esquema de nomes

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:

Antes:

# mount toolbox:/tools/epubs /tools/epubs

 Depois:

# mount toolbox:/tools/epubs /tools/epubs

# mount backpack:/tools/cae /tools/cae

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:

No servidor toolbox:

# cd /usr/local

# ls

bin.mips bin.sun3 bin.sun4 bin.vax

No cliente:

# mount toolbox:/usr/local/bin.`arch` /usr/local/bin

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:

No servidor toolbox:

# cd /usr/local

# ls
bin bin.mips bin.sun3 bin.sun4

bin.vax man share src

No cliente:

# mount toolbox:/usr/local /usr/local

/* monta os arquivos compartilhados */

# mount toolbox:/usr/local/bin.`arch` /usr/local/bin

/* monta os binários específicos a arquitetura */

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. PC/NFS

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 O primeiro passo é definir um domínio NIS, através

do comando net ypdomain:

net ypdomain nesales

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.

o 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:

net ypset nishost

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:

net pcnfs authserver

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 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:

net start rdr

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:

/usr/etc/pcnfs /usr/tmp

7.3. Utilização

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.
7.3.1. Montando sistemas de arquivos

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

c> net use s: \\wahoo\home\stern

c> net use f: \\mahimahi\tools\dos

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.

7.3.2. Verificando permissões de arquivos

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:

c> net name stern * c> 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.

7.3.3. Mapeamento dos nomes dos arquivos

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:

o iniciando com pontos;

o extensão DOS ilegal;

o prefixos maiores que 8 (oito) caracteres;

o múltiplos pontos;

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

caracteres;

o letras maiúsculas.

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

UNIX REGRA
letras minúsculas letras maiúsculas
qualquer um dos cinco primeiros caracteres substitui pelo símbolo (~)
não válidos
nome inválido substitui os três últimos caracteres por (~) e
dois caracteres no sufixo

Tabela 7.3.1 - Regras de converssão UNIX para DOS

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_

7.3.4. Links Simbólicos

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.

7.3.5. Conversão dos arquivos UNIX para 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.

7.4.1. Selecionando uma impressora

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:

c> net use lpt1: \\wahoo\lw1

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.

7.4.2. Redirecionando uma saída de impressã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.

c> net print foo.txt lpt1:

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:

net route gatehost

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:

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).

o 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.

o 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.

o 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.