Hoje olho para Network File System (NFS), grupo de protocolos e produtos no largo uso com redes TCP/IP-based. O NFS é especialmente popular com redes UNIX, mas está disponível agora para muitas plataformas e trabalha bem através de uma rede local. Também olho para vários protocolos que se associam estreitamente com o NFS, como Network Information Service (NIS) e o Serviço de Execução Remoto (REI).
O texto de hoje concentra-se nas versões UNIX destes protocolos, simplesmente porque servem de uma ilustração excelente. Para outros sistemas operacionais, os nomes de arquivos e procedimentos poderiam modificar-se, mas os fundamentals são compatíveis. Mostro alguns exemplos de usar máquinas de PC para o NFS e NIS como apropriado.
O movimento a processamento distribuído e arquiteturas de cliente/servidor significou que muitos usuários têm máquinas pequenas, potentes na sua escrivaninha que se comunicam com um servidor maior em algum lugar em uma rede. As aplicações as necessidades de usuário muitas vezes localizam-se em lugares outros do que no seu desktop, assim algum método de acessar arquivos remotos (aplicações e dados) necessitam-se. Embora tanto Telnet como rlogin permitam a um usuário use uma máquina remota, nenhum sistema se aproveita da máquina de mesa do usuário. A repartição periférica também ficou importante quando as redes locais crescem. Para ajudar a integrar estações de trabalho em redes locais, bem como simplificar o acesso a arquivos remoto e a repartição periférica, os Microsistemas de Sol introduziram Network File System (NFS).
O sol projetou o NFS para que permitisse a máquinas de vendedores diferentes colaborar, mesmo se usassem sistemas operacionais diferentes. O sol publicou as especificações de NFS, permitindo a outros vendedores adotar o seu próprio hardware e software para trabalhar lisamente com o NFS. Isto resulta em uma rede completamente homogênea. Desde a introdução de Sol, o NFS tornou-se um padrão de fato entre ambientes UNIX, com o forte apoio em outros sistemas operacionais, também.
O NFS de fato refere-se tanto a um produto como a um protocolo. Há um produto de NFS que se compõe do grupo de protocolos de tarefas diferentes (estes examinam-se na seção intitulada "Protocolos de NFS"). O protocolo de NFS é um protocolo do produto de NFS que trata com o acesso a arquivos. Para evitar a confusão, deve pensar no protocolo de NFS especificamente (em vez do jogo de produto inteiro) quando o NFS se menciona hoje.
O NFS empata-se intimamente agora UNIX, e embarca-se como parte da versão de software System V Release 4. Também se ata a TCP/IP, que permanece o protocolo de comunicações da escolha de redes UNIX. Para outros sistemas operacionais, o NFS é normalmente uma extensão que se acrescenta na opção de administrador de sistema. Os sistemas de UNIX usam o processo nfsd para dirigir o acesso a NFS, com o processo começado automaticamente quando as botas de sistema UNIX depois do NFS se configuraram propriamente.
O NFS permite a uma aplicação ler e escrever arquivos que residem em servidores de NFS, com o acesso ao servidor de NFS completamente transparente à aplicação e o usuário. Para desenvolvedores, o NFS não necessita nenhuma extra codificação ou manejo especial, que o faz especialmente atraente. Este acesso transparente à estrutura de arquivo de outra máquina realiza-se anexando logicamente o servidor de NFS ao cliente, um processo chamou a montagem.
O sistema de arquivos de servidor de NFS pode anexar-se no conjunto, ou somente uma porção dele pode montar-se. O diretório no qual o monte ocorre chama-se o ponto de montagem. O conceito de arquivos compartilhados semelhantes a isto encontrado com o NFS chama-se às vezes um sistema de arquivos distribuído, embora isto seja um erro de nome com o NFS.
UNIX teve a capacidade de montar ou anexar outro sistema de arquivos por muito tempo. Este tipo da montagem pode ocorrer através de redes e é transparente à aplicação e usuário, enquanto os nomes de arquivo consideram o nome do caminho cheio do sistema de arquivos montado. O monte de NFS é semelhante ao processo de monte de UNIX.
O NFS usa o termo cliente para representar qualquer máquina que solicita um arquivo de outra máquina, que é o servidor. A multiparalelização de sistemas operacionais pode atuar tanto como cliente como como servidor simultaneamente, com processos nos arquivos de acesso de máquina em outra máquina enquanto os outros na rede acessam o seu próprio disco rígido. Normalmente, as restrições impõem-se quanto aos arquivos ou as porções do sistema de arquivos que pode compartilhar-se, tanto para considerações de velocidade como segurança. As instalações de NFS típicas usam computadores pessoais ou estações de trabalho diskless como clientes que acessam um sistema de servidor mais potente. Como os sistemas operacionais de computador pessoais como MS-DOS são paralelização única, os PCs normalmente só atuam como clientes, a menos que dirijam um sistema operacional de multiparalelização como Windows NT ou OS/2. É possível ter uma rede inteira de multiincumbir computadores que compartilham os seus passeios um com outro, embora na prática isto trabalhe bem só para pequenas redes por causa da alta densidade do tráfego de rede necessitado apoiar todos os sistemas de arquivos montados.
Por causa da necessidade de transferir arquivos rapidamente, a velocidade de rede fica vitalmente importante. Quando se projetou, a meta original de um sistema de arquivos montado pelo NFS foi fornecer a realização equivalente a 80 por cento da realização esperada de um disco rígido localmente montado. Isto põe a ênfase de realização tanto no passeio de disco de NFS como no sistema de rede. Tipicamente, os passeios de disco de NFS estão entre o disponível mais rápido, especificamente para reduzir gargalos no fim de passeio. O hardware de rede e o software devem escolher-se para permitir a quantidade tratada mais rápida possível.
Como o NFS é baseado em UNIX, a segurança oferecida é rudimentar. Por essa razão, o Sol introduziu o NFS Seguro, que implementa um protocolo transmissor criptografado da proteção acrescentada contra o acesso não autorizado a sistemas de arquivos montados pelo NFS.
O produto de NFS compreende vários protocolos, só um dos quais se chama o protocolo de NFS. Os protocolos de produto de NFS projetam-se como grupo de camadas, semelhantes ao modelo OSI. As camadas do produto de NFS são em comparação com as camadas OSI na Figura 12.1. Cada protocolo no produto de NFS tem uma Internet RFC dedicado à sua especificação.
A figura 12.1. Camadas de protocolo de NFS.
O produto de NFS é baseado no modelo em camadas OSI, resultando em protocolos que são independentes (na teoria, pelo menos) um de outro e protocolos em camadas diferentes. A filosofia de desenho é que qualquer protocolo de camada única pode substituir-se com algum outro, supondo que a funcionalidade do protocolo fosse o mesmo. Até agora não há alternativas comuns dos dois produtos de camada mais baixa, RPC e XDR, embora haja vário para a camada superior.
O texto fonte tanto da Chamada de procedimento remoto (RPC) como de Representação de Dados Externa (XDR) protocolos está disponível gratuitamente de Microsistemas de Sol.
A figura 12.1 introduz o RPC (Chamada de procedimento remoto) e XDR (Representação de Dados Externa) protocolos para que olho agora mais detalhadamente.
O protocolo de Chamada de procedimento remoto (RPC) atua como a camada de sessão e como o cambista de mensagem de todas as aplicações baseadas no NFS. RPC compõe-se do grupo de procedimentos que podem incorporar-se em aplicações de alto nível para tratar qualquer acesso a rede necessário. Os procedimentos remotos não são mais complicados para usar do que procedimentos locais.
RPC desenvolveu-se especialmente para o NFS mas encontrou desde então o uso em outras suites de protocolo. Os princípios cobertos aqui aplicam àqueles produtos RPC, também.
Os desenvolvedores de aplicações podem criar os seus próprios procedimentos RPC entre um cliente (aquele que emite o pedido) e um servidor (aquele que processa o pedido). Chamam um grupo de procedimentos um serviço. Cada servidor pode usar só um serviço, portanto cada serviço se destina um número de programa para identificar-se tanto ao cliente como ao servidor.
RPC funciona sobre a rede entre um cliente e um servidor. O processo seguido de um RPC mostra-se na Figura 12.2. Começa com a ativação do procedimento pelo cliente, do qual uma mensagem de pedido se envia ao servidor. Depois de receber a mensagem e extrair o pedido, o servidor realiza o procedimento solicitado e reúne uma mensagem de resposta com os resultados. Recebendo a resposta, o cliente desmonta a mensagem e continua com a execução normal da aplicação. Cada passo do procedimento controla-se por rotinas dentro da biblioteca RPC (que se liga nas aplicações).
A figura 12.2. A execução de um RPC.
As mensagens de RPC podem enviar-se usando TCP ou UDP (ou no que diz respeito ao assunto, qualquer outro protocolo que fornece a mesma funcionalidade). Tipicamente, RPC usa-se com UDP porque um protocolo baseado na conexão não é necessário e UDP é normalmente mais rápido. Contudo, UDP realmente impõe um tamanho de pacote máximo, que pode causar alguns problemas com procedimentos. Também, UDP não garante a entrega, portanto uma aplicação que usa UDP deve tratar questões de confiança (normalmente com um cronômetro de retransmissão).
O uso de TCP oferece a capacidade não só para ignorar assuntos de confiança (deixando isto ao software TCP), mas também a pedidos de lote. Com uma conexão de lote, o cliente e o servidor aceitam que o cliente pode enviar vários pedidos de RPC um após o outro sem esperar pela confirmação da ordem ou uma resposta a cada um. Isto pode ser uma característica útil com algumas aplicações.
O protocolo RPC usa-se para enviar pedidos e respostas. O formato da cabeçada de pacote de protocolo RPC mostra-se na Figura 12.3, com todos os campos codificados na Representação de Dados Externa (XDR) formato (ver a seção intitulada "Representação de Dados Externa (XDR)" depois hoje). O campo de carteira de identidade Transacional usa-se para combinar com pedidos e respostas e modifica-se (normalmente incrementado) pelo cliente com cada novo pedido. O campo de Indicador de Direção mostra se a mensagem se originou com o cliente (um valor de 0) ou com o servidor (um valor de 1). O primeiro Número da versão é a versão de RPC usado e o segundo Número da versão identifica a versão do programa. O Número de Programa identifica o serviço (o jogo de procedimentos) para usar, como mencionado antes. O Número de Procedimento identifica o determinado procedimento no serviço.
A figura 12.3. A cabeçada de protocolo RPC.
Alguns procedimentos poderiam necessitar que um cliente se autenticasse ao servidor, tanto com objetivos de identificação como por razões de segurança. A cabeçada de protocolo RPC contém dois campos da autenticação. O campo de informação de Autorização é para a própria informação, e o campo de Verificação de Autorização usa-se para a validação. O RPC RFC não define como a autenticação deve executar-se, deixando-o até o desenvolvedor de aplicações, mas realmente especifica dois campos com um tamanho máximo de 400 bytes cada um. Há atualmente quatro tipos da autenticação predestinada para o uso:
O único sistema de autenticação que é realmente seguro é o método DES. Outros três sistemas podem quebrar-se prontamente por um desenvolvedor informado.
Cada serviço que usa RPC tem um número de programa que unicamente o identifica ao protocolo. RPC guarda a pista de conexões usando um número de programa para cada um, de que podem fazer o mapa a um nome do programa. Em UNIX, este mapeamento executa-se no arquivo/etc/rpc. Uma amostra/etc/rpc arquivo segue:
portmapper 100000 portmap sunrpc rstat_svc 100001 rstatd rstat rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd etherstatd 100010 etherstat rquotad 100011 rquotaprog quota rquota sprayd 100012 spray 3270_mapper 100013 rje_mapper 100014 selection_svc 100015 selnsvc database_svc 100016 rexd 100017 rex alis 100018 sched 100019 llockmgr 100020 nlockmgr 100021 x25.inr 100022 statmon 100023 status 100024 bootparam 100026 ypupdated 100028 ypupdate keyserv 100029 keyserver ypxfrd 100069 ypxfr pcnfsd 150001 pcnfsd
Este arquivo mostra o nome do programa e o seu número de programa correspondente. A terceira coluna, quando presente, mostra um nome do programa que corresponde ao nome de processo na primeira coluna. Os números de programa mostrados neste arquivo destinam-se pelo RPC RFC e devem ser consistentes através de todas as implementações de RPC.
As conexões entre um cliente e servidor são sobre portos, cada um com o seu próprio número (os números de porto usam-se em TCP/IP para definir uma conexão). Para prevenir problemas com a alocação de porto usando RPC, um porto mapper desenvolveu-se. Sem o porto mapper, um servidor pode ficar facilmente sem portos disponíveis com só algumas conexões RPC ativas.
O porto mapper controla uma mesa de portos e programas RPC usando aqueles portos. O porto mapper ele mesmo tem um número de porto dedicado (porto 111 tanto com UDP como com TCP). Os portos disponíveis para conexões RPC destinam-se quando o programa RPC se inicia, em que tempo estes números de porto se enviam ao porto mapper.
Quando um cliente quer usar RPC, envia um pedido ao servidor. Este pedido segue o formato de cabeçada RPC visto na Figura 12.3 e inclui o número da versão de RPC, o número de serviço e o protocolo a usar-se. O porto mapper então pode alocar um número de porto conveniente e regresso que número em uma mensagem de resposta ao cliente. Uma vez que um número de porto destinou-se para aquele cliente, mantém-se, para que todos os pedidos de procedimento venham dentro daquele porto até que a aplicação termine. Os números de porto poderiam manter-se sobre vários processos, portanto a interrogação de porto só tem de conduzir-se uma vez entre ciclos de poder de sistema.
Este procedimento realmente tem um desconto: o cliente deve saber o endereço do servidor. Simplesmente não pode distribuir um pedido genérico em um servidor com os serviços que procura. Isto superou-se com alguns sistemas de arquivos de rede recentemente desenvolvidos, embora não NFS.
A Representação de Dados Externa (XDR) é o método pelo qual os dados se codificam dentro de uma mensagem RPC (ou outros sistemas de protocolo, também). Não há cabeçada de mensagem formal ou o sistema de protocolo de XDR, embora o XDR RFC realmente defina o método de codificar dados.
XDR usa-se para assegurar que os dados de um sistema são compatíveis com outros. Poderia parecer que nenhuma definição formal se necessita, mas considere o caso de uma máquina baseada em EBCDIC que se comunica com uma máquina baseada em ASCII. XDR permite a ambos os fins converter da sua representação de dados local a um formato comum, retirando qualquer dúvida da significação dos dados. (EBCDIC a ASCII não é o problema de conversão principal. Alguns sistemas usam altos bits como significante, e os outros usam bits baixos. Também, os formatos para definir tipos de números se diferenciam consideravelmente.)
O formato de XDR usa bits sequentes escritos em um buffer, logo formatado em uma mensagem e enviado às camadas de protocolo mais baixas. XDR confia em um byte de 8 bits, com os bytes mais baixos que são o mais significante. O RFC define aquele todo número inteiro os tipos de dados convertem-se em números inteiros de 4 bytes, com um formato de hipernúmero inteiro de 64 bits extenso disponível. IEEE os formatos de 32 bits usam-se para números de ponto flutuante, onde o mantissa é 23 bits mais baixos, o representante toma 8 bits, e o sinal do número é 1 bit. Onde os dados tomam menos de 4 bytes de qualquer tipo, o enchimento acrescenta-se para assegurar comprimentos de 4 bytes.
Uma oferta especial parecida a uma linguagem C chamou XDR desenvolveu-se para simplificar o manejo de dados de XDR-formato. Pode usar-se de dentro de outras linguagens de programação.
O protocolo de NFS compõe-se do grupo de procedimentos de RPC. Não é um protocolo no sentido convencional de definir um complexo handshaking processo entre duas máquinas. Em vez disso, é um método da informação que se comunica sobre um procedimento a dirigir-se. O NFS usa UDP e tem um número de porto de 2049 destinado. Este número de porto é absurdo; resulta de um erro na implementação original que não pode corrigir-se posteriormente por causa de questões de compatibilidade. Como os números de porto se destinam pelo porto mapper, este número não tem verdadeira significação.
O NFS projetou-se para ser um protocolo sem pátria, significando que as máquinas usando o NFS não teriam de manter mesas estatais para usar o protocolo. Também, se projetou para ser robusto, significando que depois de fracassos (de uma conexão ou uma máquina) o sistema pode recuperar-se rapidamente e facilmente.
O protocolo de NFS é difícil de descrever sem introduzir alguma programação, porque o sistema se descreve quanto a língua XDR. Este tipo da discussão está além do alcance deste livro; para mais informação, refira-se ao RFCs. Contudo, é possível transmitir um sentido dos conteúdos do protocolo por um resumo das suas capacidades e características.
Para entender os procedimentos de NFS que compreendem o protocolo, é necessário examinar as estruturas de dados e objetos no protocolo. O NFS define o grupo de constantes que se usam para estabelecer vários parâmetros, como o número de bytes em um nome do caminho, o número máximo de bytes em um lido ou escrever solicitar, ou o tamanho de um ponteiro de NFS. Estes chamam-se constantes de protocolo e devem ser o mesmo de todas as implementações do NFS.
Um objeto de dados é grupo de variáveis ou valores que se combinam em uma entidade, muito como uma entrada em um livro telefônico se compõe de fato de um nome, endereço e número de telefone. As três variáveis ou os valores combinam-se para formar uma entrada única ou objeto.
Vários objetos de dados usam-se pelo NFS para definir arquivos e os seus atributos. Como o NFS trata especificamente com arquivos, estes objetos são importantes para o protocolo. Um objeto de dados é a maçaneta de arquivo (ou fhandle), que unicamente identifica um arquivo no servidor. As maçanetas de arquivo fornecem-se em todas as mensagens de NFS que se referem ao arquivo. Como com a maior parte de tipos de dados de NFS, a maçaneta de arquivo é um campo de 32 bytes do formato livre que é compreensível pelo servidor. Por exemplo, um arquivo UNIX define-se unicamente pelo seu dispositivo números principais e menores e o seu número inode. O próprio nome de arquivo não se usa.
Um objeto de dados usa-se para o tipo de arquivo (chamou ftype), que define todas as espécies de arquivos conhecidos pelo NFS. Estes imitam os tipos de arquivo UNIX, inclusive um arquivo regular (qualquer espécie de dados), um diretório (que é uma entrada de arquivo em UNIX), conexões (que são vários ponteiros abaixo de nomes diferentes para o mesmo arquivo) e ambo o bloco e arquivos de modo de caráter.
Também usado é uma estrutura de dados dos atributos de arquivo, chamados mais gordos. Isto define as permissões do arquivo, os tempos do acesso, o proprietário e vários outros parâmetros. Isto é necessário sempre que um arquivo lido ou escreva executa-se, porque os atributos devem ser corretos para permitir ao procedimento continuar. (Os atributos podem modificar-se por outro procedimento de NFS chamado atributos de jogo ou sattr.)
Estes objetos de dados podem combinar-se em uma entidade maior usando uma união distintiva. Uma união distintiva é uma combinação de vários objetos de dados que se dão uma etiqueta única. Podem pensar nestas uniões distintivas como uma etiqueta seguida de dados, que poderiam diferenciar-se dependendo do resultado de um procedimento. Por exemplo, depois que um procedimento realizou-se, uma união distintiva poderia ser uma etiqueta seguida de uma mensagem de erro ou do resultado do procedimento, se realiza propriamente. A união, entretanto, entrega-se a pela etiqueta e não se preocupa com os conteúdos na área de dados. Este tipo da estrutura usa-se para simplificar a programação.
Dezessete procedimentos (e um procedimento NULO) definem-se dentro do protocolo de NFS. Estes procedimentos resumem-se na Tabela 12.1. Este livro não entra no detalhe sobre os procedimentos, como não são relevantes para o nível da discussão. O RFC cobre todos eles no detalhe exaustivo.
|
Nome |
Descrição |
|
Nulo |
Procedimento nulo |
|
Atributos de arquivo de esforço |
Devolve os atributos de um arquivo |
|
Atributos de arquivo de jogo |
Estabelece os atributos de um arquivo |
|
Leia a raiz de sistema de arquivos |
Não usado; agora obsoleto |
|
Nome de arquivo de busca |
Devolve a maçaneta de arquivo que corresponde a um nome de arquivo |
|
Leia conteúdos da conexão |
Detalhes de regressos de conexões simbólicas a um arquivo |
|
Leia arquivo |
Lê um arquivo |
|
Escreva esconder |
Não usado |
|
Escreva entrar |
Escreve um arquivo |
|
Crie arquivo |
Cria um novo arquivo e devolve a maçaneta do novo arquivo |
|
Elimine arquivo |
Elimina um arquivo |
|
Renomeie arquivo |
Renomeia um arquivo |
|
Gere conexão |
Cria uma conexão a um arquivo (o mesmo sistema de arquivos) |
|
Gere a conexão simbólica |
Gera uma conexão simbólica (através de sistemas de arquivos) |
|
Diretório Create |
Cria um novo diretório |
|
Diretório Delete |
Retira um diretório |
|
Diretório Read |
Devolve uma lista de arquivos no diretório |
|
Leia atributos de sistema de arquivos |
Informação sobre regressos sobre o sistema de arquivos |
Os programadores poderiam ter notado a falta de qualquer função de arquivo aberta e fechada dentro do NFS. Isto resulta da natureza sem pátria do protocolo. Quando um arquivo deve abrir-se, o processo de NFS local trata-o, não o processo remoto. Isto leva em conta o melhor controle de arquivos e portos depois do fracasso de uma máquina ou uma conexão.
Na introdução de hoje mencionei que o NFS trabalha montando um sistema de arquivos de servidor de NFS para um sistema de arquivos de cliente. Como acaba de ver, contudo, o protocolo de NFS é de fato sobre acesso a arquivos e informação, não unindo sistemas de arquivos. Este procedimento de montagem de sistema de arquivos trata-se como uma questão separada pelo produto de NFS, usando o protocolo de Monte. O monte usa UDP.
O protocolo de Monte implica-se na restituição de uma maçaneta de arquivo do servidor ao cliente, permitindo ao cliente acessar uma área no sistema de arquivos de servidor. O protocolo devolve não só a maçaneta de arquivo mas também o nome do sistema de arquivos no qual o arquivo solicitado reside. O monte compõe-se de um número de procedimentos que facilitam comunicações entre o cliente e servidor, projetado especialmente para tratar com arquivos.
Um processo chamou mountd cuida do manejo do protocolo de monte em ambos os fins de uma conexão. O processo de mountd mantém uma lista de máquinas e nomes do caminho que se implicam em uma operação de monte. Uma vez que um monte executou-se, o NFS pode continuar funcionando sem referir-se atrás para Aumentar em absoluto. Isto deixa o Monte continuar modificando as suas mesas internas sem afetar sessões contínuas. Isto pode causar um problema se um cliente cair e se reunir. O servidor ainda manda enumerar as conexões originais nas suas mesas de Monte internas. Para corrigir este problema, a maior parte de clientes de NFS enviam uma ordem (chamou UMNTALL, ou não monte todos) a todos os servidores de NFS quando inicializam.
O protocolo de Monte só implica-se durante a conexão original entre um cliente e um servidor. O processo de mountd guarda a pista de conexões, mas uma vez que a conexão se estabelece, o protocolo de Monte abandona todo o controle ao NFS. Todo o NFS tem de acessar um sistema de arquivos é uma maçaneta de arquivo válido (que Monte provê quando a conexão se faz).
Como mencionado antes, o protocolo de Monte compõe-se do grupo de procedimentos. Estes resumem-se na Tabela 12.2 e são evidentes.
|
Nome |
Descrição |
|
NULO |
Nulo |
|
MNT |
Monta um sistema de arquivos e devolve a maçaneta de arquivo e nome de sistema de arquivos |
|
UMNT |
Não monta um sistema de arquivos de servidor, eliminando a entrada da mesa de Monte |
|
UMNTALL |
Não montes todos os sistemas de arquivos de servidor usados pelo cliente e atualizações a mesa de Monte |
|
EXPORTAÇÃO |
Fornece uma lista de sistemas de arquivos exportados |
|
MONTÃO |
Fornece uma lista dos sistemas de arquivos no servidor que se montam atualmente no cliente |
Algumas versões do NFS permitem uma capacidade de automonte, na qual os sistemas de arquivos remotos se montam só quando necessitado. Isto impede-os de anexar-se durante períodos prolongados do tempo e simplifica a administração. O processo da automontagem é completamente transparente ao usuário.
A capacidade de automonte constrói-se de acordo com procedimentos de NFS, mas executa alguns truques inteligentes. O automounter não é parte do NFS mas é uma aplicação que se senta em cima dele. As conexões simbólicas são a chave à operação do automounter.
Ocasionalmente um administrador de sistema quer prevenir o acesso a um sistema de arquivos disponível para o NFS. Tais exemplos ocorrem regularmente durante a manutenção, as atualizações de software, ou proteger dados durante um determinado processo. UNIX tem a capacidade de trancar um determinado arquivo modificando permissões, e o mesmo pode fazer-se para sistemas de arquivos até certo ponto, mas pareceria intuitivo que o fechamento de um sistema de arquivos mais se implica do que trancar simplesmente um arquivo ou dois. A capacidade de trancar sistemas de arquivos do acesso não se desenvolveu com o produto de NFS original mas implementou-se como um serviço paralelo depois que o NFS ficou mais largamente disponível.
Separar funcionalidade (como fechamento de arquivo) em protocolos separados ou procedimentos é compatível tanto com o OSI como com filosofia de NFS. Isto também permite a melhor portabilidade e a compatibilidade através de plataformas.
O fechamento de sistema de arquivos trata-se por vários protocolos e procedimentos, implicando alguns processos de demônio. No sistema de fechamento de arquivo original desenvolvido por Microsistemas de Sol, um demônio de fechadura chamou lockd usou-se. Isto precisa que cada atividade RPC que implica uma fechadura se comunique com o processo, mesmo quando está em outra máquina. As comunicações entre RPC e lockd usam um protocolo chamado Kernel Lock Manager (KLM), que monta em UDP.
Sempre que se chame um procedimento de fechadura, o lockd decide se pode tratar a tarefa na máquina local ou se as mensagens têm de enviar-se a processos de lockd remotos (em outras máquinas). As comunicações entre processos de lockd diferentes são por outro protocolo chamado Network Lock Manager (NLM). Há várias versões tanto de KLM como de NLM no uso, com implementações disponíveis para a maior parte de plataformas de hardware.
Um processo chamou statd (monitor de posição) controla o estado de fechaduras e trata perguntas contra um sistema de arquivos trancado. Isto é necessário para que uma nova pergunta contra um sistema de arquivos trancado possa fazer-se fila (se se trancar para um pouco tempo) ou rejeitou (se o sistema de arquivos se tranca durante algum tempo).
Há vários sistemas de proteção construídos do fechamento de arquivo, como cronômetros automáticos para prevenir o fechamento infinito depois de um choque de máquina, pedidos contrários em fechaduras e um período curto da realização de procedimentos existentes antes que uma fechadura se conclua. Estes definem-se todos e explicam-se no RFC.
O Serviço de Execução Remoto (REI) projeta-se para permitir a um usuário dirigir ordens em outra máquina com variáveis de ambiente cheias, sem incorrer os de cima de processos como Telnet, rlogin, ou rsh. O REI usa rexd chamado de um demônio que corre no servidor e emprega serviços de NFS. (Lembre-se de que cada máquina pode ser tanto cliente como servidor, portanto a maior parte de máquinas de multiparalelização em uma rede podem dirigir rexd.) o REI usa-se comumente quando algumas aplicações se instalam em só algumas máquinas mas devem estar disponíveis para todos os usuários.
O REI tem uma vantagem importante quanto a outra utilidade UNIX deste tipo do serviço. Permite o acesso aos dados da máquina local realizando a ordem no remoto. Isto permite a um usuário dirigir uma aplicação em outra máquina acessando arquivos de dados na máquina local. Também permite aos recursos de outra máquina usar-se sem começar um processo de concha de usuário ou registrar em log na máquina remota.
Para dirigir uma aplicação ou realizar uma ordem em uma máquina remota, o REI segundo a ordem usa-se. A sintaxe acrescenta o nome da máquina na qual a ordem é realizar-se e a ordem de correr. O seguinte código dá um exemplo disto:
$ hostname tpci_hpws4 $ cat file1 This is the file "file1" on "tpci_hpws4". This is the client machine. $ on merlin hostname merlin $ rsh merlin cat file1 cat: cannot open file1 $ on merlin cat file1 This is the file "file1" on "tpci_hpws4". This is the client machine.
Este exemplo mostra a máquina remota realizando uma ordem de gato em um arquivo local. Quando a utilização de ordens de corridas de máquina remota em, um ambiente idêntico ao cliente se estabelece no remoto, inclusive usuário e carteiras de identidade de grupo e variáveis de ambiente. Deste modo, se a máquina remota no exemplo prévio tivesse file1 chamado de um arquivo, mas não esteve no caminho de pesquisa do processo que dirige a ordem, o sistema ainda se referiria atrás ao cliente do arquivo.
Duas utilidade disponível para usuários de NFS é exemplos simples de programas RPC. Também são úteis para o usuário que quer verificar a posição de conexões e a carga de uma máquina remota.
O programa de borrifo é semelhante para silvar em que envia um lote de mensagens através da rede e espera por respostas. Várias opções apoiadas podem configurar o uso do borrifo. Quando a ordem de borrifo se emite com a opção-c, envia um número fornecido de datagramas à máquina remota e tempos os resultados. Um uso típico mostra-se aqui:
$ spray -c 200 beast sending 200 packets of length 86 to beast... in 18.3 seconds elapsed time, 4 packets (2.00%) dropped by beast Sent: 10 packets/sec, 912 bytes/sec Recd: 9 packets/sec, 862 bytes/sec
O programa rusers dá-lhe uma ideia de quem se registra em log em máquinas remotas. Uma produção típica é o seguinte:
$ rusers beast.tpci.com tparker bsmallwood rmaclean merlin.tpci.com ychow etreijs tgrace tpci_hpws3.tpci.com tparker sysadm tpci_hpws4.tpci.com pepper
Como mostrado, a produção do programa rusers inclui o nome de máquina e a lista de usuários naquela máquina. Algumas implementações apoiam opções para rusers, ao passo que alguns têm a produção que se diferencia ligeiramente.
Muitas pessoas gostam de usar o serviço de NFS quando enfrentam ele como um usuário mas se assustam para configurá-lo atuando como um administrador de sistema. A suposição geral é que o processo deve ser enrolado, complexo, e necessitar muito conhecimento sobre os sistemas operacionais. Por essa razão, muitas pessoas não se incomodam com o NFS, que é uma vergonha porque é um dos serviços mais úteis que TCP/IP tem de oferecer. Como vê nesta seção, não é difícil implementar uma rede de NFS.
Configuro o NFS em dois sistemas operacionais diferentes para mostrar o processo geral. Uso um SCO UNIX máquina como um exemplo de uma instalação UNIX e um Windows do sistema de Grupos de trabalho para mostrar fundar um cliente e sistema de PC de NFS de servidor. Começo com a máquina UNIX, porque UNIX se associa muitas vezes com servidores de NFS.
O serviço de NFS faz o uso extensivo do serviço RPC. Por essa razão, o demônio de servidor RPC deve estar correndo atrás do NFS a implementar-se. Em alguns sistemas UNIX pode verificar se RPC é ativo emitindo esta ordem na concha pronta:
rpcinfo -p
Deve ver uma lista de todos os servidores RPC que atualmente correm na sua máquina. Se RPC estiver correndo propriamente, vê quatro listagens rpcbind (dois para UDP e dois para TCP) e uma entrada de pcnfsd, demônio de NFS. Esta ordem não mostra toda esta produção de algumas versões de UNIX, inclusive SCO UNIX.
Para SCO UNIX, o NFS começa-se e dá-se uma passada uma escrita chamou/etc/nfs. Isto pode ligar-se nas rotinas de lançamento para carregar o NFS automaticamente quando as botas de sistema ligando o arquivo/etc/nfs ao arquivo/etc/rc2.d/sname. Para fechar o NFS propriamente, também tem de ligar/etc/nfs ao arquivo/etc/rc0.d/kname. (Em outras implementações UNIX a modificação de nomes de arquivo, mas o acesso geral é o mesmo.) Se quiser começar e parar o demônio de NFS manualmente, pode fazer isto com estas ordens:
/etc/nfs start /etc/nfs stop
A ordem de/etc/nfs lança e fecha o demônio de servidor de NFS quando a ordem apropriada se emite. Quando emite a ordem de partida, os demônios que se ativam ecoam-se à tela:
$ /etc/nfs start Starting NFS services: exportfs mountd nfsd pcnfsd biod(x4) Starting NLM services: statd lockd
Com uma ordem de parada, vê uma mensagem que os demônios e o servidor se fecham:
$ /etc/nfs stop NFS shutdown: [NFS Shutdown Complete]
Para um sistema de arquivos em um SCO UNIX máquina para estar disponível para clientes de NFS em outras máquinas, o sistema de arquivos deve enumerar-se no arquivo UNIX/etc/exports. Com algumas versões de UNIX, os demônios de NFS começam-se automaticamente se o arquivo/etc/exports existir durante o tempo de inicialização. Isto invoca exportfs chamado de um programa que estabelece o sistema de arquivos como disponível para o uso de NFS. Se alguma modificação se fizer ao arquivo/etc/exports enquanto o sistema corre, pode emitir outra ordem de exportfs, ou simplesmente reiniciar a máquina, para fazer as modificações eficazes.
O formato do arquivo/etc/exports é como se segue:
directory [ -option, option ... ]
O diretório é o nome de caminho do diretório ou arquivo a compartilhar-se (exportado, na terminologia de NFS) pelo NFS, e as opções são um do seguinte:
ro: Exporte o diretório como somente de leitura. (O valor à revelia deve exportar como lido - escrevem.)
rw=hostnames: Exporte o diretório como lido pela maior parte, que significa somente de leitura para a maior parte de máquinas mas leia - escrevem a máquinas especificamente identificadas.
anon=uid: Se um pedido de NFS vier de um usuário desconhecido, use uid como a carteira de identidade de usuário eficaz de propriedade e permissões.
root=hostnames: Dá o acesso a raiz aos usuários de raiz de uma máquina especificada.
access=client: Dá o acesso a monte a cada cliente enumerado. Um cliente pode ser um nome do host ou um grupo líquido.
Um exemplo de um arquivo/etc/exports ajuda a mostrar o uso destas opções. Um sinal de libra (#) em uma linha significa um comentário. Aqui está uma amostra/etc/exports arquivo:
/usr/stuff -ro # export as read-only to anyone /usr -access=clients # export to the group called clients /usr/public # export as read-write to anyone
O NFS está pronto agora para o uso no SCO UNIX o servidor. Poderia notar que SCO UNIX cria/etc/xtab chamado de um novo arquivo que contém a informação sobre sistema de arquivos do arquivo de exportações. Não deve modificar os conteúdos do arquivo/etc/xtab ou o servidor de NFS não pode funcionar propriamente. O arquivo/etc/xtab gera-se pela ordem de exportfs.
Algumas versões de UNIX usam a ordem de ação de fundar um diretório da exportação. (SCO o UNIX não apoia a ordem de ação porque as funções se duplicam no arquivo/etc/exports.) A sintaxe da ordem de ação é como se segue:
share -F nfs -o options -d description path
A opção-F indica que o diretório ou os arquivos dados no caminho devem estabelecer-se como sistemas de arquivos de NFS. As opções depois de-o estabelecem o tipo do acesso do mesmo modo que o SCO UNIX opções para o arquivo/etc/exports mostrado antes. A opção-d pode seguir-se de uma afirmação descritiva usada por clientes para descrever o sistema de arquivos de exportação. Por exemplo, para compartilhar o diretório/usr/public como lido - escrevem (o default), pode emitir esta ordem:
share -F nfs -d "Server public directory" /usr/public
As opções podem combinar-se, como mostrado neste exemplo:
share -F nfs -o ro=artemis,anon=200 -d "Book material" /usr/tparker/book
Esta ordem compartilha o diretório/usr/tparker/book, que se marca com a descrição "Reservam o material", com todo o mundo como lido - escrevem exceto artemis chamado de uma máquina, para o qual é somente de leitura. Qualquer usuário anônimo que acessa o sistema usa UID 200.
A ordem de ação por si mesmo normalmente mostra uma lista de todos os sistemas de arquivos que se exportam.
UNIX pode montar que um NFS exportou o sistema de arquivos de outra máquina com a ordem de monte. A sintaxe para montar um sistema de arquivos de NFS é como se segue:
mount -F nfs -o options machine:filesystem mount-point
A opção-F diz à ordem de monte que o sistema de arquivos é um sistema de arquivos de NFS; o machine:filesystem é o nome da máquina remota e o sistema de arquivos a montar-se; e o ponto de montagem é a posição no sistema de arquivos atual onde o sistema de arquivos remoto deve montar-se. Algumas versões de UNIX modificam a sintaxe um pouco. Por exemplo, SCO UNIX usa um caso mais baixo f e NFS maiúsculo para indicar o tipo. Verifique as páginas de homem a sintaxe exata na sua versão.
No uso, o monte é fácil trabalhar com. Por exemplo, a ordem
mount -F nfs artemis:usr/public /usr/artemis
monta que o sistema de arquivos/usr/public na máquina remota chamou artemis para a máquina local no diretório chamou/usr/artemis. O ponto de montagem (neste caso/usr/artemis) deve existir para o monte para ter sucesso.
O componente opcional-o da ordem de monte pode usar-se para estabelecer opções da seguinte lista:
rw: Faz que o monte leia - escrevem (o valor à revelia)
ro: Estabelece o monte no somente de leitura
timeo=x: Dá um valor de intervalo no décimo de um segundo para tentar o monte antes de desistir
retry=x: Novas tentativas x tempos antes de desistir
suave: Força o cliente a abandonar a tentativa de monte se um reconhecimento não se receber da máquina remota
muito: O cliente continua tentando montar o sistema de arquivos até bem sucedido
enterre: Permite ao teclado interromper o pedido de monte; de outra maneira, as tentativas continuam para sempre
Alguma destas opções pode combinar-se em uma ordem de monte, como podem ser para a ordem de ação. Por exemplo, a linha de comando
mount -F nfs -o soft,ro artemis:usr/public /usr/artemis
tentativas de montar o diretório/usr/public em artemis como somente de leitura, mas desiste se a tentativa de monte não se reconhecer por artemis. A ordem de monte por si mesmo normalmente mostra todos os sistemas de arquivos montados.
Várias suites TCP/IP e os pacotes de aplicações do Windows 3.x, o Windows 95 e Windows NT fornecem o suporte de NFS. Um dos mais largos usados é ChameleonNFS de NetManage, que pode usar-se abaixo de alguma das versões de sistema operacional de Windows. ChameleonNFS permite a uma máquina de Windows atuar tanto como cliente como como servidor do acesso a arquivos de NFS. Em outras palavras, outra máquina pode acessar arquivos na máquina de ChameleonNFS, e a máquina de ChameleonNFS pode acessar arquivos em outras máquinas equipadas do NFS.
Implementar acesso a NFS em uma máquina de Windows pode variar do muito complexo ao muito fácil, dependendo do pacote de software que fornece as capacidades de NFS. Alguns produtos de NFS disponíveis não oferecem capacidades de servidor, permitindo só o comportamento de cliente de NFS na máquina de instalação. Cuidadosamente verifique o software antes que o compre ou instale para assegurar que adquire um produto que encontra as suas exigências de NFS. Nesta seção continuo com ChameleonNFS como o software NFS de exemplo, porque é relativamente fácil instalar, configure, e uso. Uso o Windows 3.11 como o exemplo de sistema operacional.
ChameleonNFS confia em um demônio de software chamado Portmapper, que mantém uma lista de todos os serviços de rede atualmente registrados (inclusive o NFS). Portmapper carrega-se automaticamente quando as botas de máquina de Windows na maior parte de instalações. ChameleonNFS faz-se para registrar passeios montados ao WIN.INI arquivo (para o Windows 3.x pelo menos) sempre que uma sessão de Windows se salve. Isto permite a passeios atualmente montados remontar-se automaticamente quando a seguinte sessão de Windows se começa.
As atividades de servidor de ChameleonNFS como administração e configuração conduzem-se pelo ícone NFS no grupo de programa NetManage. A única exceção é impressora que trata para dispositivos de rede, que se trata pelo ícone Printer no Painel de controle. As atividades de cliente de NFS fazem-se por Aplicações para Windows normais, como o Gerente de Arquivo e Painel de controle. Os passeios montam-se e não montam-se pelo Gerente de Arquivo, ao passo que todas outras opções se tratam pela lista de Rede no Painel de controle.
Uma vez instalado, ChameleonNFS deixa-o montar um diretório remoto em um servidor de NFS do Gerente de Arquivo. Selecione a opção de Conexões de Rede do menu descendente Disk. Isto expõe o diálogo de Conexões de Rede mostrado na Figura 12.4. O nome de máquina remoto e o diretório a montar-se especificam-se neste diálogo. O sistema de arquivos montado monta-se normalmente como outro passeio, não como parte do sistema de arquivos de um passeio existente.
A figura 12.4. O diálogo de Conexões de Rede deixa-o montar um sistema de arquivos remoto usando o NFS.
Se quiser ver todos os sistemas de arquivos que estão disponíveis para aumentar em uma máquina remota, usam o Botão "browse". O nome de máquina remoto e todos os sistemas de arquivos disponíveis enumeram-se, como mostrado na Figura 12.5. Na Figura 12.5 o único sistema de arquivos que mostra como disponível na máquina chamou tpci é o sistema de arquivos de raiz, que significa o sistema de arquivos inteiro no remoto. Não pode contar desta janela se se estabelece para direitos de acesso especiais tal como somente de leitura.
A figura 12.5. Quando especifica o nome do host no diálogo Pesquisar, os sistemas de arquivos de NFS de toda aquela repartícula de pó enumeram-se.
Clicando na Tecla OK depois que o nome de máquina remoto e o nome do diretório enchem-se em montes o sistema de arquivos remoto na posição que indica na janela, como mostrado na Figura 12.6. Isto monta o diretório de raiz da máquina remota como passeio H na máquina local. Quando clica em OK para fechar o diálogo de NFS, o sistema de arquivos da máquina remota está disponível do Gerente de Arquivo. O ícone de passeio mostra que é um passeio de rede.
A figura 12.6. Esta janela mostra que o diretório de raiz de tpci deve montar-se como passeio H na máquina local.
Para desconectar NFS-mounted drive, use o botão Disconnect no diálogo de Conexões de Rede. O ícone de passeio deve retirar-se do Gerente de Arquivo para mostrar que o monte não é já realmente.
ChameleonNFS pode usar-se para compartilhar passeios de PC ou diretórios com outros usuários na rede. Para compartilhar um passeio, crie uma lista de usuários que têm o acesso ao passeio, a menos que todo o mundo possa montar os passeios. A lista de acesso de usuário mantém-se de acordo com o ícone NFS com ChameleonNFS. Comece o processo de servidor de NFS clicando no ícone NFS no grupo de programa Chameleon. Isto expõe a janela principal NFS. Clicar no item de menu Users na janela NFS abre a janela Server Users, mostrada na Figura 12.7. Daqui pode acrescentar e dirigir todo o acesso ao seu NFS passeios disponíveis. Para entrar em um usuário, datilografe o nome, qualquer senha que quer que eles usem (se quiser uma senha), e um grupo e número de identificação de usuário. Clique no botão Add, e a entrada aparece como parte da lista de usuário.
A figura 12.7. A janela Server Users deixa-o estabelecer direitos de acesso aos seus passeios de NFS.
Depois de ter entrado em todos os usuários, clique no botão Save para escrever as entradas no disco. Se não salvar a mesa, qualquer modificação perde-se. A figura 12.8 mostra a dois usuários na mesa de acesso.
A figura 12.8. Permite-se que dois usuários acessem os passeios de NFS da máquina local.
Depois, tem de estabelecer os passeios e diretórios que podem exportar-se por outros clientes. Use o item de menu Exports na janela NFS para expor a janela Server Exports. Use o browser diretivo para mover-se entre os passeios e diretórios, selecionando aqueles quer exportar. Clique no botão Add para entrar no passeio e combinação diretiva à lista de exportação.
A figura 12.9 mostra a janela Server Exports com dois diretórios específicos e um jogo de passeio inteiro a exportar-se. Para cada passeio ou diretório pode estabelecer direitos de acesso clicando no botão Access. Isto expõe o diálogo de Acesso, que pode usar para selecionar as permissões próprias e direitos de acesso.
A figura 12.9. A janela Server Exports com diretórios e passeios define-se para o acesso a NFS.
Uma vez que as permissões de acesso estabelecem-se, um cliente remoto pode acessar os seus passeios de NFS. O usuário remoto incita-se a uma senha se tenha feito que o seu sistema necessite aquele.
O protocolo de Páginas amarelas (YP) é um serviço de camada de aplicação RPC (como NFS) que fornece um serviço diretivo versátil. Por causa de restrições de direitos autorais, as Páginas amarelas renomearam-se a Network Information Service (NIS), embora ambos os termos sejam de uso comum. NIS desenvolveu-se por várias razões, mas aquele que toca usuários a maioria é permissões de acesso. O efeito que estas permissões têm em usuários é geralmente transparente exceto uma vantagem principal.
Se for usuário em uma grande rede e tende a unir-se a outras máquinas frequentemente (por Telnet ou FTP, por exemplo), deve manter contas em cada máquina à qual se une. Assim, precisaria de contas de usuário em cada máquina que pode querer de modo conceptível acessar. A manutenção das senhas em um grande número de máquinas é desajeitada, porque deve registrar em log em cada um e executar modificações de senha. NIS desenvolveu-se para permitir a um arquivo de usuário único, central compartilhar-se sobre a rede, necessitando só uma entrada única permitir o acesso a todas as máquinas (a menos que as restrições específicas se imponham), e a simplificação de uma modificação de senha em todas as máquinas a um passo.
Em termos de RPC, esta combinação de carteira de identidade de usuário e senha trabalha nos procedimentos de autenticação RPC. RPC usa o usuário e carteiras de identidade de grupo para conceder o acesso a arquivos, portanto é necessário para o cliente e usuário de servidor e carteiras de identidade de grupo combinar. Sem NIS isto pode ser muito difícil de implementar porque o arquivo de usuário de cada máquina poderia ter os mesmos nomes, mas as suas carteiras de identidade de usuário não poderiam coincidir. Pior, outro usuário com uma carteira de identidade de usuário que combina em outra máquina pode acessar arquivos na sua máquina como se ele ou ela se logassem como você.
NIS é um sistema de acesso distribuído naquela cada máquina na rede que usa acessos NIS um servidor central, chamado o mestre NIS ou ypmaster (dependendo da versão), para a informação sobre acesso. Em redes maiores, para estender a carga, e para todas as redes como uma contingência de reserva, várias outras máquinas indicam-se como escravos ou ypslaves que mantêm a informação sobre acesso atualizada. Em caso de um fracasso do servidor principal, um escravo toma as funções. NIS usa tanto TCP como UDP de comunicações.
Há duas versões de NIS no uso geral. O primeiro lançamento (a Versão 1) tinha problemas sérios em certas circunstâncias, portanto a Versão 2 se lançou rapidamente. Contudo, alguns sistemas ainda usam a mais velha versão.
O protocolo NIS manda definir o grupo de procedimentos dentro do RFC. Estes permitem uma procura de servidores principais, acesso aos arquivos de usuário e funções de gestão de sistema. Outro procedimento usa-se para transferir cópias dos arquivos mestres. Várias máquinas agrupam-se em uma subrede de NFS, chamada um domínio (para não se confundir com o domínio de Internet). Cada domínio tem máquinas de escravo e mestre.
NIS guarda a informação sobre acesso no grupo de mapas, cada mapa que corresponde a uma determinada área ou o domínio de uma rede. Isto leva em conta vários grupos para usar o mesmo mestre NIS mas ter permissões de acesso diferentes. Os mapas de NIS não têm de corresponder a domínios DNS, permitindo mais versatilidade na configuração. Os mapas compõem-se do grupo de registros no formato de ASCII, cada um com uma chave de índice da busca rápida. A chave de índice é normalmente o nome do usuário. Os registros têm a mesma estrutura que arquivos de usuário normais (como/etc/passwd de UNIX), tanto para a compatibilidade como para a simplicidade.
O uso de NIS não nega a necessidade de um conjunto completo de arquivos de acesso em cada máquina, porque NIS se carrega depois que a máquina inicializou-se (e estes arquivos leem-se). Os arquivos autônomos devem ter acesso de um administrador de sistema pelo menos, embora seja a boa prática para incluir também os usuários mais frequentes em caso de um acesso a prevenção de choque de rede aos diretórios NIS.
NIS não se restringe aos usuários de um sistema. Qualquer arquivo pode fundar-se para usar NIS, como a lista de máquinas em uma rede (o arquivo/etc/hosts de UNIX). Assim, só uma modificação tem de fazer-se a estes arquivos em qualquer rede. O grupo de pseudônimos também pode dirigir-se por NIS.
Várias ordens NIS-específicas implicam-se com o protocolo, embora a maior parte de administradores de sistema fundem pseudônimos para minimizar o impacto em usuários. Para a maior parte de usuários, só uma ordem é necessária em uma base regular. Para sistemas UNIX, isto é a ordem yppasswd para modificar a senha de um usuário. Isto é normalmente aliased a passwd, ordem de modificação de senha normal. Os desenvolvedores de aplicações deveriam examinar o protocolo NIS mais detalhadamente escrevendo o cliente/servidor codificar o que corre em um sistema baseado em NIS, mas os efeitos do sistema distribuído são normalmente transparentes.
Antes hoje viu como NIS pode usar-se para fornecer o acesso por toda a rede a arquivos que seriam normalmente locais, oferecendo o acesso muito melhorado de usuários e administradores. Com o NIS ativo, não precisa de manter uma corrente separada/etc/passwd arquivo em cada sistema UNIX; em vez disso, pode usar os arquivos de senha principais NIS para permitir o acesso global a qualquer máquina na rede.
Nesta seção olho para como fundar NIS em uma rede UNIX simples. Há muitas variações de arquitetura de rede e configurações, algumas das quais se tornam terrivelmente complexas para um administrador de rede. Embora os princípios de fundar NIS e domínios NIS sejam o mesmo de todas as redes, alguns extra passos necessitam-se em organizações muito complexas. Em sua maioria, olho para os fundamentos só. Os arquivos que se tratam normalmente por NIS são como se segue:
|
/etc/ethers |
Ethernet MAC a mapeamentos de endereço IP |
|
/etc/group |
Informação sobre acesso de grupo |
|
/etc/hosts |
Endereço IP a mapeamentos hostname |
|
/etc/netmasks |
Máscaras de rede de IP |
|
/etc/passwd |
Informação sobre acesso de usuário |
|
/etc/protocols |
Protocolo de rede e mapeamentos de número |
|
/etc/rpc |
Números de RPC |
|
/etc/services |
Número de porto a mapeamentos de protocolo TCP/IP |
Olho para os arquivos o mais comumente usados quando fundei o mestre NIS e escravo NIS, bem como olhando para o que tem de modificar-se em qualquer máquina de cliente que quer usar NIS.
Os domínios de NIS ordenam-se normalmente agrupar máquinas com um mestre NIS e um ou vários escravos NIS como apoio. Um domínio NIS não tem de ser o mesmo como um domínio de Internet, embora para a maior parte de redes sejam idênticos (em outras palavras, a rede inteira é o domínio NIS). O domínio NIS tem de ter um nome, que também pode corresponder ao seu nome de domínio de Internet. Alternativamente, pode fundar domínios subsidiários de pequenos grupos lógicos em uma grande corporação, como domínios de contabilidade, pesquisa e desenvolvimento e marketing.
Para fundar um domínio NIS, tem de decidir o nome de domínio e saber o endereço IP do mestre NIS e qualquer escravo NIS. Se tiver mais de um domínio NIS estabelecido, tem de saber que máquinas se tratam por que mestre NIS. Cada máquina no domínio (se um ou muitos domínios se estabelecem) deve introduzir-se em um arquivo de configuração para permitir à máquina de cliente usar NIS.
Para fundar o domínio NIS, tem de registrar em log em cada máquina de cliente na rede e fundar o nome de domínio com a seguinte ordem:
domainname domain
o domínio é o nome de domínio os usos de máquina. Tem de logar-se como raiz ou uma conta administrativa com o acesso à utilidade de raiz para estabelecer estes valores. Como este tipo da ordem é só eficaz até que a máquina se reinicie, é melhor entrar no nome de domínio em um do lançamento rc escritas. Estes diferenciam-se para cada versão de UNIX, portanto deve verificar as suas ordens de rc de descobrir onde embutir o nome de domínio. Normalmente está em um arquivo de acordo com o diretório/etc/rc.d.
NIS usa vários demônios no servidor e em todos os clientes para permitir o sistema NIS. No mestre NIS e qualquer escravo NIS, o demônio chama-se normalmente ypserv. O demônio ypserv espera por pedidos de cliente de entrada no serviço, logo trata-os.
Nos clientes, o processo ypbind usa-se. Isto é responsável por unir-se com o mestre NIS quando as botas de máquina e a determinação de qualquer resolução dão passos necessárias para tratar senhas de entrada e outra informação sobre configuração sobre rede tratada por NIS. O processo de ter ypbind une-se ao mestre NIS e estabelece procedimentos chama-se uma atadura, porque o cliente se ata ao mestre de pedidos.
O processo obrigatório começa com ypbind o envio de uma mensagem de transmissão de qualquer mestre NIS na rede para responder com o seu endereço IP e o número de porto para remeter pedidos. Se mais de um mestre NIS responder ao pedido, só a primeira resposta recebida se usa. Se por alguma razão o ypbind encontrar que não adquire respostas do mestre NIS, supõe que o mestre tenha espatifado e retransmita um pedido em um mestre.
Pode descobrir a que mestre NIS qualquer máquina de cliente se ata com a ordem ypwhich. Normalmente responde com o nome do mestre NIS, como mostrado aqui:
$ ypwhich merlin
Fundar um mestre NIS é normalmente franco. Comece verificando os arquivos existentes na máquina principal, como/etc/passwd e/etc/group, para assegurar que a informação é exata e atual. Deve retirar qualquer conta vencida ou não desejada, por exemplo, e verificar que todos os diretórios de senha de entrada e as ordens são corretos. Enquanto examina o arquivo/etc/passwd, verifique para assegurar-se que todas as contas têm senhas. Se não fazem, destinam uma senha ou retiram a conta. Com um sistema NIS por toda a rede no lugar, cada um pode explorar estes buracos de segurança para ganhar o acesso a qualquer máquina na rede, inclusive o mestre NIS e máquinas de portão.
Uma vez que os arquivos estão prontos para a geração de mapa de NIS, assegure-se que se loga como raiz (para estabelecer a propriedade própria e assegurar o acesso cheio ao sistema de arquivos). Os mapas de NIS geram-se dos arquivos de UNIX padrão, usando a ordem de ypinit com a opção-m. A opção-m indica que esta máquina é o mestre NIS. Da raiz pronta, emita a seguinte ordem:
/usr/sbin/ypinit -m
O caminho para o programa ypinit poderia ser diferente no seu sistema UNIX. Verifique o caminho se a ordem produzir uma mensagem de erro tentando realizar.
Quando a ordem de ypinit realiza, esquadrinha todos os arquivos NIS denominados no arquivo/var/yp e produz os mapas de NIS que se usam pelos processos de cliente. O arquivo/var/yp poderia ter um nome do diretório diferente em alguns sistemas, como SCO UNIX, que usa/etc/yp como um diretório de todos os arquivos NIS. Verifique a sua documentação de sistema UNIX ou páginas de homem de posições de arquivo próprias. O arquivo/var/yp contém uma lista de todos os mapas a gerar-se, e normalmente não tem de fazer nenhuma modificação deste arquivo.
Cria-se um novo diretório (normalmente chamava/var/yp/domainname, onde domainname é o nome de domínio NIS). Os mapas colocam-se neste novo diretório. Se estiver fundando mais de um domínio todos tratados pela mesma máquina principal NIS, os mapas de cada domínio são abaixo do subdiretório do nome de domínio.
Como o passo último em ypinit, perguntam-lhe que máquinas são servidores de escravo NIS, em que ponto deve digitar os seus nomes. Os nomes de escravo salvam-se em um arquivo no diretório de domínio.
Depois que os mapas geraram-se propriamente, pode começar o demônio ypserv. É o melhor para automatizar o lançamento editando o lançamento rc arquivos para fazer isto para você quando as botas de máquina. Há uma seção em um arquivo rc (normalmente aquele que começa RPC) que parece a isto:
if [ -f /etc/yp/ypserv -a -d /var/yp/`domainname` ] then /etc/yp/ypserv fi
Esta escrita verifica a existência do diretório/var/yp/domainname, onde domainname é o nome de domínio do seu domínio NIS. A entrada na primeira linha onde domainname se localiza deve estar em citações traseiras únicas, que significa que a concha deve realizar a ordem de domainname e usar os resultados. Se o diretório existir, o demônio ypserv começa-se. Deve substituir os caminhos diretivos com os usados pelo seu sistema UNIX.
Para começar manualmente o demônio ypserv, logue como raiz e emita a ordem
/etc/yp/ypserv
ou tudo o que o caminho para o seu demônio ypserv é.
Depois, tem de começar o demônio ypbind no servidor, também (de outra maneira, o ypserv não pode encontrar os mapas). Novamente, isto faz-se normalmente pelas escritas de lançamento rc com uma entrada como isto:
if [ -d /var/yp ] then /etc/yp/ypbind fi
Novamente, deve verificar que o caminho diretivo é correto. Pode começar o demônio ypbind manualmente emitindo-o na linha de comando quando logado como raiz. Assegure-se que o caminho diretivo é correto quando faz assim.
Se quer executar um teste rápido dos demônios NIS, emitir uma ordem como este na linha de comando:
ypmatch tparker passwd
A ordem de ypmatch pede que NIS use os mapas para experimentar o seguinte argumento com o mapa do nome do terceiro argumento. Neste exemplo, o ypmatch instruem-no a olhar no arquivo passwd (passwd é o pseudônimo a passwd.byname) para a entrada de tparker. Deve devolver a linha que combina. Pode usar qualquer combinação de pseudônimo de mapa e entrada que sabe existe para testar o demônio de servidor NIS.
Para fundar um escravo NIS, o mestre NIS deve configurar-se e gerência. Quando está seguro que o mestre é operacional, logue como raiz à máquina a fundar-se como o escravo NIS. O nome de domínio do escravo deve estabelecer-se propriamente antes que a configuração pode prosseguir, portanto verifique o lançamento rc ordens da entrada que estabelece a variável domainname ou use a ordem de domainname de estabelecer o nome de domínio.
Para fundar o escravo NIS e propagar os arquivos NIS do mestre ao escravo, emita a ordem
/etc/yp/ypbind
substituir por qualquer caminho é correto no seu sistema. Verifique que a atadura ao mestre é correta emitindo a ordem de ypwhich. Deve devolver o nome principal NIS.
Finalmente, emita a ordem
/etc/yp/ypinit -s servername
onde o caminho é correto e servername é o nome do seu mestre NIS. O ypbind-s opção funda a máquina local como um escravo. Os conjuntos de comandos ypbind diretórios na máquina local e transferências todos os mapas do mestre ao escravo.
Depois que a organização é completa, pode testar a organização de escravo com a ordem de ypmatch, como mostrado na seção prévia.
Para atualizar os mapas nos escravos regularmente, a ordem de ypxfr usa-se no escravo, seguido do nome do mapa a transferir-se. Por exemplo a ordem
ypxfer passwd.byname
transfere o arquivo passwd.byname do mestre ao escravo. A maior parte de administradores criam o grupo cron entradas para transferir todos os arquivos NIS regularmente (tal como à noite). Também pode usar um arquivo de escrita realizado por um administrador de rede.
Fundar um cliente NIS precisa que tenha o jogo de domainname propriamente, com a ordem de domainname ou com uma entrada nos arquivos de lançamento rc, e que a ordem de ypbind se emitiu propriamente e o cliente NIS ata-se ao servidor NIS.
Como mencionado antes, quando uma entrada no/etc/passwd ou arquivo/etc/group deve procurar-se um jogo, os arquivos locais examinam-se primeiro, então o servidor questiona-se se nenhum jogo se encontrar. Para instruir o seu cliente para ir ao mestre NIS combinar com uma senha de entrada, tem de acrescentar a seguinte entrada no fundo do arquivo/etc/passwd:
+:*:0:0:::
Se souber o formato das entradas de arquivo/etc/passwd, reconhecerá isto como uma entrada legal sem informação especificada. O mais o sinal no campo username deve instruir ypbind para questionar o mestre NIS. Isto chama-se uma entrada de marcador. O mais a entrada de sinal pode estar em qualquer lugar no arquivo. Quando se consegue, NIS usa-se, então o arquivo lê-se como antes se nenhum jogo se tenha encontrado.
RPC e o NFS têm dois instrumentos de administração primários disponíveis para fornecer atualizações de posição e indicações da preocupação dentro do sistema: rpcinfo e nfsstat. Normalmente estes instrumentos não estão disponíveis para usuários finais, embora seja útil saber da sua existência e o seu papel na monitorização de NFS e RPC.
Dirigir qualquer instrumento único não é normalmente suficiente para isolar um problema. Muitas vezes um instrumento informa um problema com um porto, mas depois do exame mais fechado se considera que o porto funciona mas o processo em outro fim morreu. Por isso, estes instrumentos projetam-se para acostumar-se como um complemento um a outro até que um diagnóstico exato possa conseguir-se.
O programa rpcinfo controla o porto mapper da máquina na qual corre, e pela rede, o porto mappers de servidores. Como o porto mapper é o programa que controla o acesso a RPCs, este tipo da informação é importante no rastreamento de problemas. O programa rpcinfo pode expor os conteúdos das mesas de mapeamento, mostrando o porto e números de programa de cada conexão, e pode ativar servidores remotos para testar uma conexão.
Tipicamente, o rpcinfo chama-se com a opção-p de mostrar a lista de programas RPC de que segue a pista atualmente o porto mapper. Um nome de máquina opcional pode acrescentar-se só para expor conexões com uma máquina. Uma produção típica do programa rpcinfo mostra-se aqui:
$ rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100008 1 udp 1026 walld
150001 1 udp 1027 pcnfsd
150001 2 udp 1027 pcnfsd
100002 1 udp 1028 rusersd
100002 2 udp 1028 rusersd
100024 1 udp 1029 status
100024 1 tcp 1024 status
100020 1 udp 1034 llockmgr
100020 1 tcp 1025 llockmgr
100021 2 tcp 1026 nlockmgr
100021 1 tcp 1027 nlockmgr
100021 1 udp 1038 nlockmgr
100021 3 tcp 1028 nlockmgr
100021 3 udp 1039 nlockmgr
Em caso de um problema que contata com o porto mapper, o rpcinfo devolve uma mensagem de erro. Em tal caso, o porto mapper não funciona corretamente e pode não haver contato com outras máquinas. Um cheque usando o silvo verifica isto. Um exemplo desta espécie da mensagem de erro fatal mostra-se aqui:
$ rpcinfo -p rpcinfo: can't contact port mapper: RFC: Remote system errer -125
As conexões específicas podem testar-se com rpcinfo usando a máquina e nome de processo, como as seguintes demonstrações de exemplo:
$ rpcinfo -u merlin walld program 100008 version 1 is ready and waiting
Observe que a opção-u se usa para conexões UDP, ao passo que-t deve usar-se com conexões TCP. Neste exemplo, o cliente rpcinfo enviou um pedido ao programa especificado e esperado por uma resposta. Uma resposta bem sucedida resulta na mensagem mostrada aqui. Se uma resposta não se receber antes que um cronômetro vença, uma mensagem de erro expõe-se.
Na produção de mostra prévia, há pcnfsd chamado de um processo, que é um servidor RPC desenvolvido para o uso com máquinas baseadas de MS-DOS. Trata direitos de acesso e serviços de spooling do lado de DOS, simplificando o acesso a máquina de DOS a serviços de NFS.
O programa nfsstat, como o seu nome sugere, fornece a estatística sobre o número e o tipo de pedidos de RPC que se fazem. Chama-se normalmente sem uma opção, embora vário existam (dependendo da implementação e versão) para mostrar a estatística específica ou partes de mostra só certas da conexão.
A produção de nfsstat mostra-se aqui para uma pequena rede típica:
Server rpc: calls badcalls nullrecv badlen xdrcall 10465 0 0 0 0 Server nfs: calls badcalls 10432 0 null getattr setattr root lookup readlink read 1 0% 24 0% 1 0% 0 0% 10123 0% 0 0% 5 0% wrcache write create remove rename link symlink 0 0% 2 0% 0 0% 1 0% 0 0% 1 0% 0 0% Client rpc: calls badcalls retrans badxid timeout wait newcred 8273 2 0 0 0 0 0 Client nfs: calls badcalls 8263 0 null getattr setattr root lookup readlink read 1 0% 24 0% 1 0% 0 0% 10123 0% 0 0% 5 0% wrcache write create remove rename link symlink 0 0% 2 0% 0 0% 1 0% 0 0% 1 0% 0 0%
A produção de nfsstat é útil para diagnosticar problemas de conexão. O valor mostrado como badcalls mostra o número da mensagem RPC incorreta processada pelo sistema. Os valores de nullrecv e badlen mostram o número de mensagens vazias ou incompletas. O valor de xdrcall mostra o número de erros na compreensão de mensagens.
Para o lado de cliente, o badxid mostra o número de mensagens recebidas que não combinaram com um pedido enviado (baseado nos números de identificação). O intervalo e os valores de retrans mostram o número de vezes que uma mensagem teve de ser ressentem-se. Se estes números forem altos, normalmente significa que a conexão é demasiado lenta ou há uma falta com UDP. O valor esperar mostra o número de vezes um processo teve de atrasar-se por causa de uma falta de portos disponíveis.
Estes tipos da estatística são úteis para configurar RPC propriamente. Os administradores de sistema podem ajustar (torcem) valores do sistema de NFS e controlam os seus efeitos sobre a realização dentro de algum tempo.
O Sistema de arquivos de Rede tem uma reputação de ser complexo e ornery. Não é nenhum. Em vez disso, o NFS é uma solução elegante para um problema e um no uso comum. Hoje examinei o conceito e a arquitetura básica do NFS, confiantemente sem atolar-me nos detalhes.
Também lhe mostrei como NIS trabalha, e como fundá-lo em uma rede. Embora cada rede seja não necessariamente um objetivo de NIS, é um serviço muito prático que é parte da família TCP/IP.
O que o NFS faz, em uma oração?
O NFS permite a uma aplicação ler e escrever arquivos que residem em máquinas remotas como se estivessem no sistema de arquivos local.
Defina o cliente e o servidor como usado no NFS.
Apesar de definições complexas da indústria de computador, este é realmente fácil. Um cliente emite um pedido. Um servidor responde-o.
Qual é o papel de RPC no NFS?
O protocolo de Chamada de procedimento remoto trata a troca de mensagem entre sistemas baseados no NFS. É grupo de procedimentos que podem chamar-se por clientes.
O que faz um porto mapper fazem?
O porto mapper fornece uma correlação entre os portos em uma máquina e as aplicações que os usam.
O que o Núcleo Tranca Gerente fazem?
O Gerente de Fechadura Central implica-se no fechamento de arquivo, prevenindo o acesso a arquivos ou sistemas de arquivos. Um pedido de fechadura de arquivo emite-se por clientes quando querem o acesso exclusivo a um arquivo. O Gerente de Fechadura Central trata pedidos de fechadura de arquivo.