diff --git a/engineering-guide/puppet/profiles/nfs_server.rst b/engineering-guide/puppet/profiles/nfs_server.rst deleted file mode 100644 index eeec8b19..00000000 --- a/engineering-guide/puppet/profiles/nfs_server.rst +++ /dev/null @@ -1,68 +0,0 @@ -``profile::nfs_server`` -======================= - -This module manages the Linux kernel NFS server and configures the exports. - -See `Implementation Notes`_ below for details. - - -Parameters ----------- - -=============================== ======== ================================================ -**Name** **Type** **Default** -------------------------------- -------- ------------------------------------------------ -exports hash hiera('nfs_server::exports') -=============================== ======== ================================================ - - -``exports`` -~~~~~~~~~~~ - -A hash containing the NFS exports to be configured. The keys are the pathnames -to be exported, the values are hashes with two attributes: - -- ``options``: the default options for the export -- ``clients``: a list of hashes describing the clients - -The hashes describing the clients have two entries as well, the second one being -optional: - -- ``hosts``: a client specification as described in :manpage:`exports(5)` -- ``options`` (optional): an option string specific to these clients - -Example:: - - nfs_server::exports: - # Make software available via NFS. Installation happens - # on builder.psi.ch. - '/exports/prog': - options: 'ro,root_squash' - clients: - - hosts: '129.129.0.0/16' - - hosts: 'builder.psi.ch' - options: 'rw,no_root_squash' - # Scratch directories for prod servers. Files on scratch - # are cleaned up by a cron job on janitor.psi.ch. - '/exports/scratch': - options: 'rw,root_squash' - clients: - - hosts: '129.129.160.0/24' - - hosts: '129.129.190.0/24' - - hosts: 'janitor.psi.ch' - options: 'no_root_squash' - - -Implementation Notes --------------------- - -We pass ``--manage-gids`` to :manpage:`rpc.mountd(8)` to avoid the following -problem. When not using Kerberos, the NFS client passes a list of groups (GIDs -really) that the user is a member of, and the server consults this list when -making access decisions. The client can pass at most 16 groups, which means that -if a user is a member of more than 16 groups, they may be denied access even -though they are a member of the necessary group. - -One solution is to use Kerberos, the other is to have the server determine group -membership itself, ignoring the client's list. The latter is what -``--manage-gids`` does.