Meu servidor de arquivos tem apenas uma grande partição compartilhando coisas em/exportações. Então, usando as exportações NFSv3 de estilo antigo que eu tinha:
/exports/home 192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
Então decidi mudar para o estilo NFSv4 e mudei para:
/exports 192.168.1.0/24(ro,fsid=0,no_subtree_check)
/exports/home 192.168.1.0/24(rw,sync,no_subtree_check)
/exports/root 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)
#/etc 192.168.1.0/24(ro,no_subtree_check) # Test entry to check export root is working.
Em seguida, alterei os comandos de montagem para exclude /exports. Com certeza /etcera inmontável (embora não tenha ocorrido erro, apenas travou até ser interrompido). No entanto, como eu esperava, /exportsas ACLs de ainda eram herdadas para baixo, todos os compartilhamentos eram somente leitura e o root era compactado em todos os lugares.
Também tentei alterar a ACL para /exports/rootuma única máquina, mas não fez diferença.
Portanto, além de poder fornecer um identificador exclusivo para os sistemas de arquivos onde tal identificador não pode ser determinado, qual é o sentido de definir uma raiz de exportação com fsid=0:
- Fazer isso reduz a flexibilidade em termos de como os compartilhamentos são configurados (ou seja, o problema de herança, a menos que em sistemas de arquivos diferentes e você use
nocrossmount?). - Supondo a configuração antiga do NFSv3, você ainda não consegue montar,
/etcentão que segurança extra ela oferece?
Só faz fsid=0sentido quando /exportsé apenas uma área de montagem para sistemas de arquivos separados que são montados lá e exportados com diferentes ACLs?
Parece-me que a configuração dos servidores NFS foi invertida. Antigamente, no Solaris, você teria todas as coisas compartilhadas diretamente montadas /exporte compartilhadas. O servidor teria /home/usero bind montado em /export/home/user. Mas agora /homeé o local real de montagem do sistema de arquivos e é montado por ligação em /exports.
Isso está correto?
Observe: Os exemplos acima são apenas para fins ilustrativos, portanto, não faça comentários sobre a sabedoria de não usar no_squash_root, eu sei.
Muito obrigado.
Responder1
É uma mudança arquitetônica na forma como o protocolo de “montagem” do NFS funciona.
No NFSv2/v3 havia um protocolo RPC 'MOUNT' totalmente separado que permitia ao cliente obter um identificador de arquivo de qualquer sistema de arquivos exportado por seu caminho. Mas no WebNFS subsequente - e mais tarde no NFSv4 - a montagem foi alterada para uma operação NFS em banda e, ao mesmo tempo, a operação foi alterada para retornar um único identificador de arquivo "raiz" do qual todas as pesquisas de caminho descendem. (Na verdade, o WebNFS tinha duas dessas raízes, sendo outra uma raiz "pública" para URLs nfs://, que não chegou ao NFSv4.)
Portanto, para que a operação 'PUTROOTFH' funcione, deve haverseralgum tipo de sistema de arquivos raiz, já que não é mais possível pular as etapas - todas as travessias de caminho são uma série de operações compostas [PUTROOTFH, LOOKUP, LOOKUP, ..., LOOKUP, OPEN]. Isso reflete o 9p do Plan9, bem como o SMBv2/3.
(Tudo isso implica que neste estilo, os caminhos do sistema de arquivos exportados tornam-se relativos à raiz, por exemplo, seu /exports/home é montado como "foo:/home",nãocomo "foo:/exportações/home".)
A falta de uma operação MOUNT(path) também é o que torna "crossmnt" implícito, pois hánão équalquer coisa que resta para montar, é tudo apenas 'LOOKUP' desde a raiz.
Na prática, o NFSv4 pode usar qualquer um dos estilos – se uma exportação "fsid=0" não estiver definida, o kernel Linux (2.6.33 ou posterior)irá gerar automaticamente uma /raiz virtual para vocêque não contém nada, exceto montagens para seus locais exportados regulares. (Isso também tem a vantagem de manter caminhos de montagem idênticos entre NFSv3 e NFSv4.) Em outras palavras, você pode realmente continuar usando sua configuração original no estilo v3.