sous-chefs / nfs Goto Github PK

View Code? Open in Web Editor NEW

40.0 25.0 91.0 406 KB

Development repository for the nfs cookbook

Home Page: https://supermarket.chef.io/cookbooks/nfs

License: Apache License 2.0

Ruby 86.18% HTML 13.82%

chef-cookbook hacktoberfest chef-resource managed-by-terraform nfs chef

nfs's Introduction

nfs cookbook

Description

Installs and configures NFS client and server components

Maintainers

This cookbook is maintained by the Sous Chefs. The Sous Chefs are a community of Chef cookbook maintainers working together to maintain important cookbooks. If you’d like to know more please visit sous-chefs.org or come chat with us on the Chef Community Slack in #sous-chefs.

Requirements

Should work on any RHEL 7+, Debian 10+, Ubuntu 18.04+ distributions.

This cookbook depends on the line cookbook

Attributes

nfs['packages']
- Case switch in attributes to choose NFS client packages dependent on platform.
nfs['service']
- ['config'] - only set on Debian/Ubuntu to work around loose systemd dependencies on this platform family - debian: nfs-config.service
- ['portmap'] - the rpcbind service - default: nfs-client.target
- ['lock'] - the rpc-statd service - default: nfs-client.target, debian: rpc-statd.service
- ['server'] - the server component, - default: nfs-server.service, debian: nfs-kernel-server.service
- ['idmap'] - the NFSv4 idmap component
nfs['config']
- client_templates - templates to iterate through on client systems, chosen by platform
- server_template - Per-platform case switch in common nfs.erb template. This string should be set to where the main NFS server configuration file should be placed.
- idmap_template - Path to idmapd.conf used in nfs::client4 and nfs::server4 recipes.
nfs['threads'] - Number of nfsd threads to run. Default 8 on Linux, 24 on FreeBSD. Set to 0, to disable.
nfs['port']
- ['statd'] = Listen port for statd, default 32765
- ['statd_out'] = Outgoing port for statd, default 32766
- ['mountd'] = Listen port for mountd, default 32767
- ['lockd'] = Listen port for lockd, default 32768
nfs['v2'], nfs['v3'], nfs['v4']
- Set to yes or no to turn on/off NFS protocol level v2, or v3.
- Defaults to nil, deferring to the default behavior provided by running kernel.
nfs['mountd_flags'] - BSD launch options for mountd.
nfs['server_flags'] - BSD launch options for nfsd.
nfs['idmap']
- Attributes specific to idmap template and service.
- ['domain'] - Domain for idmap service, defaults to node['domain']
- ['pipefs_directory'] - platform-specific location of Pipefs-Directory
- ['user'] - effective user for idmap service, default nobody.
- ['group'] - effective group for idmap service, default nogroup.

Usage

To install the NFS components for a client system, simply add nfs to the run list.

name "base"
description "Role applied to all systems"
run_list [ "nfs" ]

Then in an nfs_server.rb role that is applied to NFS servers:

name "nfs_server"
description "Role applied to the system that should be an NFS server."
override_attributes(
  "nfs" => {
    "packages" => [ "portmap", "nfs-common", "nfs-kernel-server" ],
    "port" => {
      "statd" => 32765,
      "statd_out" => 32766,
      "mountd" => 32767,
      "lockd" => 32768
    }
  }
)
run_list [ "nfs::server" ]

`nfs_export` resource Usage

Applications or other cookbooks can use the nfs_export resource to add exports:

nfs_export "/exports" do
  network '10.0.0.0/8'
  writeable false
  sync true
  options ['no_root_squash']
end

The default parameters for the nfs_export LWRP are as follows

directory
- directory you wish to export
- defaults to resource name
network
- a CIDR, IP address, or wildcard (*)
- requires an option
- can be a string for a single address or an array of networks
writeable
- ro/rw export option
- defaults to false
sync
- synchronous/asynchronous export option
- defaults to true
anonuser
- user mapping for anonymous users
- the user's UID will be retrieved from /etc/passwd for the anonuid=x option
- defaults to nil (no mapping)
anongroup
- group mapping for anonymous users
- the group's GID will be retrieved from /etc/group for the anongid=x option
- defaults to nil (no mapping)
options
- additional export options as an array, excluding the parameterized sync/async, ro/rw options, and anoymous mappings
- defaults to root_squash

nfs::default recipe

The default recipe installs and configures the common components for an NFS client, at an effective protocol level of NFSv3. The Chef resource logic for this is in the nfs::_common recipe, with platform-specific conditional defaults set in the default attributes file.

nfs::client4 recipe

Includes the logic from nfs::_common, and also configures and installs the idmap service to provide an effective protocol level of NFSv4. Effectively the same as running both nfs::_common and nfs::_idmap.

nfs::server recipe

The server recipe includes the common client components from nfs::_common. This also configures and installs the platform-specific server services for an effective protocol level of NFSv3.

nfs::server4 recipe

This recipe includes the common client components from nfs::_common. It also configures and installs the platform-specific server services for an effective protocol level of NFSv4. Effectively the same as running nfs::_common and nfs::_idmap and nfs::server.

nfs::undo recipe

Does your freshly kickstarted/preseeded system come with NFS, when you didn't ask for NFS? This recipe inspired by the annoyances cookbook, will run once to remove NFS from the system. Use a knife command to remove NFS components from your system like so.

knife run_list add $NODE nfs::undo

Contributors

This project exists thanks to all the people who contribute.

Backers

Thank you to all our backers!

nfs's People

Contributors

Stargazers

Watchers

Forkers

riotgames-archive double-z cayblood nmische josephholsten greenalto c10l bryanwb vertipub jamiebuxxx quintonm ares-ensiie jblaine kuckkuck appliedcode liamoehlman criteo-forks ranxxerox imedo walbenzi reoring clockwerx gswallow jonathanserafini rtkwlf intherye endpointcorp dcigroup asmarre protec-cookbooks jessp01 kohend kojiwell joerocklin meanbee joshuaharris bsb-chris-gorrilla akistler grzegorz7 mbrukman tfly-cookbooks markgibbons shortgun yoshiwaan chris-pray kisoku davidgiesberg sergiuionescu kgintuit publicstuff the-smooth-operator altiscale gusrc pankajps czeumer zivagolee kjenney dougalb rlanore sspans parallels-cookbooks scopenco nunukim legal90 gziskind fuzzyp1neapple cnsa igorfraa raju-divakaran chuhn naturalatlas defilan mscurt kodywilson fredhutch noelafjones vancelot11 akerkhoff mhincapie rexcsn yateeshbc isabella232 enrico-usai seanpm2001

nfs's Issues

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

github-actions

.github/workflows/ci.yml

sous-chefs/.github 3.1.1

actions/checkout v4

actionshub/chef-install 3.0.0

actionshub/test-kitchen 3.0.0

actions/checkout v4

actionshub/chef-install 3.0.0

actionshub/test-kitchen 3.0.0

ubuntu 22.04

macos 14

.github/workflows/stale.yml

actions/stale v9

Check this box to trigger a request for Renovate to run again on this repository

nfs_export LWRP appends multiple anonids

I have code that looks something like this:

nfs_export "share1" do
...
anonuser "user1"
anongroup "group1"
end

nfs_export "share2" do
...
anonuser "user2"
anongroup "group2"
end

nfs_export "share3" do
...
anonuser "user3"
anongroup "group3"
end

The resulting /etc/exports file looks like this:

share1 *(rw,sync,root_squash,anonuid=user1,anongid=group1)
share2 *(rw,sync,root_squash,anonuid=user1,anongid=group1,anonuid=2,anongid=2)
share3 *(rw,sync,root_squash,anonuid=user1,anongid=group1,anonuid=2,anongid=2,anonuid=3,anongid=3)

Heads up - RHEL7.1 is broken here

See https://bugzilla.redhat.com/show_bug.cgi?id=1159308

Chef failure that surfaces. Worked in RHEL 7.0:

---- Begin output of /sbin/chkconfig nfs-lock on ----
STDOUT: 
STDERR: Note: Forwarding request to 'systemctl enable nfs-lock.service'.
Failed to issue method call: No such file or directory
---- End output of /sbin/chkconfig nfs-lock on ----

duplicate entries added to /etc/exports

This doesn't look like a dupe of #48 .

I have a new host. I've included nfs::server and I have an nfs_export stanza for /home . Unfortunately, it's adding a new entry every time. The first run is awesome:

  * nfs_export[/home] action create
    * execute[exportfs] action nothing (skipped due to action :nothing)
    * file[/etc/exports] action create
      - update content in file /etc/exports from e3b0c4 to 6c8ca7
      --- /etc/exports  2018-06-18 01:39:07.760976697 -0400
      +++ /etc/.chef-exports20180618-8749-2l9dac        2018-06-18 01:39:44.888492248 -0400
      @@ -1 +1,2 @@
      +/home 10.1.1.0/24(rw,sync,root_squash)
    * execute[exportfs] action run
      - execute exportfs -ar

So far, very cool.

Run it again:

[root@orbit ~]# !!
:
  * nfs_export[/home] action create
    * execute[exportfs] action nothing (skipped due to action :nothing)
    * append_if_no_line[export /home] action edit
      * file[/etc/exports] action create
        - update content in file /etc/exports from 6c8ca7 to e80981
        - suppressed sensitive resource

    * execute[exportfs] action run

      ================================================================================
      Error executing action `run` on resource 'execute[exportfs]'
      ================================================================================

      Mixlib::ShellOut::ShellCommandFailed
      ------------------------------------
      Expected process to exit with [0], but received '1'
      ---- Begin output of exportfs -ar ----
      STDOUT:
      STDERR: exportfs: duplicated export entries:
      exportfs:         10.1.1.0/24:/home
      exportfs:         10.1.1.0/24:/home
      ---- End output of exportfs -ar ----
      Ran exportfs -ar returned 1
:
:

I'm not modding that file or touching it outside of the LWRP, so I'm confused as to what's even triggering the newline.

This one demands a custom template as mentioned in #48 , I guess, but I'm delighted to use the nfs::server recipe for as much as it does.

Recipe: nfs::_idmap outputs Failed to start nfs-idmapd.service on Ubuntu 16.04.

I have a machine, which is running Ubuntu 16.04 Desktop, 64-bit version, that I want to set up as an NFS client.

The recipe doing this setup starts with:

include_recipe 'nfs'
include_recipe 'nfs::client4'

When cooking the machine, I get the following output:

Recipe: nfs::_common
  * apt_package[nfs-common] action install (up to date)
  * apt_package[rpcbind] action install (up to date)
  * directory[/etc/default] action create (skipped due to only_if)
  * template[/etc/default/nfs-common] action create (up to date)
  * template[/etc/modprobe.d/lockd.conf] action create (up to date)
  * service[portmap] action start (up to date)
  * service[portmap] action enable (up to date)
  * service[lock] action start (up to date)
  * service[lock] action enable (up to date)
  * service[nfs-config.service] action start (up to date)
  * service[nfs-config.service] action enable (up to date)
Recipe: nfs::_idmap
  * template[/etc/idmapd.conf] action create (up to date)
  * service[idmap] action start
    
    ================================================================================
    Error executing action `start` on resource 'service[idmap]'
    ================================================================================
    
    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '5'
    ---- Begin output of /bin/systemctl --system start nfs-idmapd ----
    STDOUT: 
    STDERR: Failed to start nfs-idmapd.service: Unit nfs-server.service not found.
    ---- End output of /bin/systemctl --system start nfs-idmapd ----
    Ran /bin/systemctl --system start nfs-idmapd returned 5
    
    Cookbook Trace:
    ---------------
    /home/janne/chef-solo/local-mode-cache/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
    /home/janne/chef-solo/local-mode-cache/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
    /home/janne/chef-solo/local-mode-cache/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
    /home/janne/chef-solo/local-mode-cache/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
    /home/janne/chef-solo/local-mode-cache/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'
    
    Resource Declaration:
    ---------------------
    # In /home/janne/chef-solo/local-mode-cache/cache/cookbooks/nfs/recipes/_idmap.rb
    
     29: service 'idmap' do
     30:   service_name node['nfs']['service']['idmap']
     31:   action [:start, :enable]
     32:   supports :status => true
     33: end
    
    Compiled Resource:
    ------------------
    # Declared in /home/janne/chef-solo/local-mode-cache/cache/cookbooks/nfs/recipes/_idmap.rb:29:in `from_file'
    
    service("idmap") do
      action [:start, :enable]
      supports {:status=>true}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      service_name "nfs-idmapd"
      pattern "idmap"
      declared_type :service
      cookbook_name "nfs"
      recipe_name "_idmap"
    end
    
    Platform:
    ---------
    x86_64-linux

The nfs-idmap service is marked as being static. I don't know the exact meaning of static:

root@asus:~# systemctl list-unit-files | grep nfs-idmap
nfs-idmapd.service                         static  
root@asus:~#

I think the name mapping works on the machine despite the failed cooking.

This make me believe that the mapping service should not be started by the nfs::_idmap recipe in this case, though I'm far from sure.

Define dependencies better?

Very useful, thanks!

We just had an issue where the awscli recipe depended on the python recipe, which then depended on any version of the build-essential recipe. build-essential then released 2.3.0 which included chef 12 specific syntax (causing a compile-time error), which then broke our deploys and was difficult to trace down.

I can see that this depends on any version of line and sysctl, can you tighten these dependencies up so there aren't any unpleasant surprises if these recipes release chef 12 only code?

I could submit a PR if you'd like.

Cannot find a provider for service on centos

It looks like the newly released version of Chef 12.4 broke this cookbook. I'm getting the following error:

       ================================================================================
       Recipe Compile Error in /tmp/kitchen/cache/cookbooks/nfs/attributes/default.rb
       ================================================================================

       ArgumentError
       -------------
       Cannot find a provider for service on centos version 6.6

       Cookbook Trace:
       ---------------
         /tmp/kitchen/cache/cookbooks/nfs/attributes/default.rb:44:in `from_file'

       Relevant File Content:
       ----------------------
       /tmp/kitchen/cache/cookbooks/nfs/attributes/default.rb:

        37:  default['nfs']['threads'] = 8
        38:  
        39:  # Default options are based on RHEL6
        40:  default['nfs']['packages'] = %w(nfs-utils rpcbind)
        41:  default['nfs']['service']['portmap'] = 'rpcbind'
        42:  default['nfs']['service']['lock'] = 'nfslock'
        43:  default['nfs']['service']['server'] = 'nfs'
        44>> default['nfs']['service_provider']['lock'] = Chef::Platform.find_provider_for_node node, :service
        45:  default['nfs']['service_provider']['portmap'] = Chef::Platform.find_provider_for_node node, :service
        46:  default['nfs']['service_provider']['server'] = Chef::Platform.find_provider_for_node node, :service
        47:  default['nfs']['config']['client_templates'] = %w(/etc/sysconfig/nfs)
        48:  default['nfs']['config']['server_template'] = '/etc/sysconfig/nfs'
        49:  
        50:  # idmap recipe attributes
        51:  default['nfs']['config']['idmap_template'] = '/etc/idmapd.conf'
        52:  default['nfs']['service']['idmap'] = 'rpcidmapd'
        53:  default['nfs']['service_provider']['idmap'] = Chef::Platform.find_provider_for_node node, :service

Recipe nfs::_common breaks on Debian 9

Encountered issue on Debian 9 host machine, running recipe on bento/debian-9. Error is reproducible every time and on MacOS Sierra too. After below is dumped, I can login to the machine, and get more info.

systemctl status nfs-common.service
● nfs-common.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)

If I try to unmask the service nothing happens.

Recipe: nfs::common
* apt_package[nfs-common] action install (up to date)
* apt_package[rpcbind] action install (up to date)
* directory[/etc/default] action create (skipped due to only_if)
* template[/etc/default/nfs-common] action create
- update content in file /etc/default/nfs-common from 7f86fe to d290a2
--- /etc/default/nfs-common 2016-12-15 13:30:00.000000000 +0000
+++ /etc/default/.chef-nfs-common20171208-1057-14p19z1 2017-12-08 18:52:31.278633301 +0000
@@ -1,20 +1,3 @@
-# If you do not set values for the NEED options, they will be attempted
-# autodetected; this should be sufficient for most people. Valid alternatives
-# for the NEED_ options are "yes" and "no".
-
-# Do you want to start the statd daemon? It is not needed for NFSv4.
-NEED_STATD=
-
-# Options for rpc.statd.
-# Should rpc.statd listen on a specific port? This is especially useful
-# when you have a port-based firewall. To use a fixed port, set this
-# this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
-# For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
-STATDOPTS=
-
-# Do you want to start the idmapd daemon? It is only needed for NFSv4.
-NEED_IDMAPD=
-
-# Do you want to start the gssd daemon? It is required for Kerberos mounts.
-NEED_GSSD=
+# Generated by Chef for broadcast-debian-9.vagrantup.com# Local modifications will be overwritten.
+STATDOPTS="--port 32765 --outgoing-port 32766"
* service[portmap] action restart
- restart service service[portmap]
* service[lock] action restart

       ================================================================================
       Error executing action `restart` on resource 'service[lock]'
       ================================================================================
       
       Mixlib::ShellOut::ShellCommandFailed
       ------------------------------------
       Expected process to exit with [0], but received '1'
       ---- Begin output of /bin/systemctl --system restart nfs-common ----
       STDOUT: 
       STDERR: Failed to restart nfs-common.service: Unit nfs-common.service is masked.
       ---- End output of /bin/systemctl --system restart nfs-common ----
       Ran /bin/systemctl --system restart nfs-common returned 1
       
       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cache/cookbooks/nfs/recipes/_common.rb
       
        46:   service component do
        47:     service_name node['nfs']['service'][component]
        48:     action [:start, :enable]
        49:     supports :status => true
        50:   end
        51: end
       
       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cache/cookbooks/nfs/recipes/_common.rb:46:in `block in from_file'
       
       service("lock") do
         provider Chef::Provider::Service::Systemd
         action [:start, :enable]
         default_guard_interpreter :default
         service_name "nfs-common"
         enabled nil
         running nil
         masked nil
         pattern "lock"
         declared_type :service
         cookbook_name "nfs"
         recipe_name "_common"
         supports {:status=>true}
       end
       
       System Info:
       ------------
       chef_version=13.6.4
       platform=debian
       platform_version=9.2
       ruby=ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]
       program_name=chef-client worker: ppid=1052;start=18:52:22;
       executable=/opt/chef/bin/chef-client
       
   
   Running handlers:
   [2017-12-08T18:52:31+00:00] ERROR: Running exception handlers
   [2017-12-08T18:52:31+00:00] ERROR: Running exception handlers
   Running handlers complete
   [2017-12-08T18:52:31+00:00] ERROR: Exception handlers complete
   [2017-12-08T18:52:31+00:00] ERROR: Exception handlers complete
   Chef Client failed. 13 resources updated in 09 seconds
   [2017-12-08T18:52:31+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
   [2017-12-08T18:52:31+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
   [2017-12-08T18:52:31+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
   [2017-12-08T18:52:31+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
   [2017-12-08T18:52:31+00:00] ERROR: service[lock] (nfs::_common line 46) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
   ---- Begin output of /bin/systemctl --system restart nfs-common ----
   STDOUT: 
   STDERR: Failed to restart nfs-common.service: Unit nfs-common.service is masked.
   ---- End output of /bin/systemctl --system restart nfs-common ----
   Ran /bin/systemctl --system restart nfs-common returned 1
   [2017-12-08T18:52:31+00:00] ERROR: service[lock] (nfs::_common line 46) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
   ---- Begin output of /bin/systemctl --system restart nfs-common ----
   STDOUT: 
   STDERR: Failed to restart nfs-common.service: Unit nfs-common.service is masked.
   ---- End output of /bin/systemctl --system restart nfs-common ----
   Ran /bin/systemctl --system restart nfs-common returned 1
   [2017-12-08T18:52:31+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
   [2017-12-08T18:52:31+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

RHEL/CentOS 7 requires rpcbind service before nfs

When calling include_recipe "nfs::server" on RHEL/CentOS 7, it is generating the following error

       Recipe: nfs::server
        (up to date)


           ================================================================================
           Error executing action `start` on resource 'service[nfs-server]'
           ================================================================================

           Mixlib::ShellOut::ShellCommandFailed
           ------------------------------------
           Expected process to exit with [0], but received '1'
           ---- Begin output of /bin/systemctl start nfs-server ----
           STDOUT:
           STDERR: Job for nfs-server.service failed. See 'systemctl status nfs-server.service' and 'journalctl -xn' for details.
           ---- End output of /bin/systemctl start nfs-server ----
           Ran /bin/systemctl start nfs-server returned 1

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/nfs/recipes/server.rb

            47: service node['nfs']['service']['server'] do
            48:   action [:start, :enable]
            49:   supports status: true
            50: end

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/nfs/recipes/server.rb:47:in `from_file'

           service("nfs-server") do
             action [:start, :enable]
             supports {:status=>true}
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             service_name "nfs-server"
             pattern "nfs-server"
             declared_type :service
             cookbook_name "nfs"
             recipe_name "server"
           end



       Running handlers:
       [2015-11-17T23:50:53+00:00] ERROR: Running exception handlers
       Running handlers complete
       [2015-11-17T23:50:53+00:00] ERROR: Exception handlers complete
       Chef Client failed. 4 resources updated in 10.300837409 seconds
       [2015-11-17T23:50:53+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       [2015-11-17T23:50:53+00:00] ERROR: service[nfs-server] (nfs::server line 47) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
       ---- Begin output of /bin/systemctl start nfs-server ----
       STDOUT:
       STDERR: Job for nfs-server.service failed. See 'systemctl status nfs-server.service' and 'journalctl -xn' for details.
       ---- End output of /bin/systemctl start nfs-server ----
       Ran /bin/systemctl start nfs-server returned 1
       [2015-11-17T23:50:55+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Looking at https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/s1-nfs-start.html, the rpcbind service should be started before the nfs service.

To resolve, I had to add the following to my cookbook:

include_recipe "nfs"
if node['platform_family'] == 'rhel' && node['platform_version'].to_f >= 7.0 && node['platform'] != 'amazon'
  service "rpcbind" do
    action [:start, :enable]
    supports status: true
  end
end
include_recipe "nfs::server"

Settings in /etc/default/nfs-common & nfs-kernel-server need to be moved to /run/sysconfig/nfs-utils on Ubuntu 16.04

Package: nfs-kernel-server
Version: 1:1.2.8-9ubuntu12.1
Ubuntu 16.04

This version of NFS uses /run/sysconfig/nfs-utils for its runtime settings.

There is a script at /usr/lib/systemd/scripts/nfs-utils_env.sh which populates /run/sysconfig/nfs-utils with settings in /etc/default/nfs-* . This script needs to be notified whenever the /etc/default/nfs-* settings change.

At present, a reboot is necessary before an NFS server starts correctly on 16.04 using this cookbook.

Incorrect nfs idmap service name for CentOS 8

Hi,

When running nfs::server4 recipe on CentOS 8 I encountered this error:

* service[idmap] action start[2020-09-30T18:08:57+00:00] INFO: Processing service[idmap] action start (nfs::_idmap line 29)

    
    ================================================================================
    Error executing action `start` on resource 'service[idmap]'
    ================================================================================
    
    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '5'
    ---- Begin output of /bin/systemctl --system start nfs-idmap ----
    STDOUT: 
    STDERR: Failed to start nfs-idmap.service: Unit nfs-idmap.service not found.
    ---- End output of /bin/systemctl --system start nfs-idmap ----
    Ran /bin/systemctl --system start nfs-idmap returned 5

I believe this is due to idmap service name being incorrect for CentOS 8, as shown in attributes here?
I think the correct service name should be nfs-idmapd instead of nfs-idmap?

$ sudo systemctl status nfs-idmapd
● nfs-idmapd.service - NFSv4 ID-name mapping service
   Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static; vendor preset: disabled)
   Active: active (running) since Wed 2020-09-30 18:08:57 UTC; 1h 37min ago
  Process: 97264 ExecStart=/usr/sbin/rpc.idmapd (code=exited, status=0/SUCCESS)
 Main PID: 97266 (rpc.idmapd)
    Tasks: 1 (limit: 47436)
   Memory: 844.0K
   CGroup: /system.slice/nfs-idmapd.service
           └─97266 /usr/sbin/rpc.idmapd

$ sudo systemctl status nfs-idmap
Unit nfs-idmap.service could not be found.

This seem to be an issue only related to nfs::_idmap recipe, as running nfs::server alone works without a problem.

Thank you!

nfs_export LWRP not truly idempotent - creates duplicate entries if things change

If I run a recipe that creates an export for /mnt/foo everything works. However, if I then change something about that export (for instance, add or remove an option), re-running the recipe will create a second entry in /etc/exports and the run will fail since the NFS server will complain that it can't handle duplicate entries.

I would think that the LWRP should look for lines based on the exported directory and update the line if it exists already.

sysctl missing

I have RHEL 7.4 with
Chef Development Kit Version: 2.2.1
chef-client version: 13.3.42
delivery version: master (73ebb72a6c42b3d2ff5370c476be800fee7e5427)
berks version: 6.3.1
kitchen version: 1.17.0
inspec version: 1.35.1
I am trying to role out an NFS server and hopefully some clients. However,
the server.rb depends on sysctl cookbook which I can no longer get.
Any work around?

nfs_exports lwrp fails if /etc/exports file is empty to start with

RHEL 7: rpc-statd and rpc-mountd ignore static ports configured for NFS server

In CentOS/RHEL 7 it's not enough just to render /etc/sysconfig/nfs to get NFS server and all the related services configured properly.

In particular, services nfs-server and rpc-statd read env variables from /run/sysconfig/nfs-utils, which is actually generated by nfs-config service on the base of /etc/sysconfig/nfs.

So, this cookbook works fine with nfs-utils-1.3.0-0.8.el7.x86_64. But if the newer version will be installed (in particular, nfs-utils-1.3.0-0.21.el7.x86_64), then the config file /run/sysconfig/nfs-utils will be not actual, without static ports.

Let me show it on the concrete example of kitchen suites:

`server-centos-71`

Converge server-centos-71 suite. There will be nfs-utils-1.3.0-0.8.el7.x86_64 installed and everything is fine there:

[root@server-centos-71 ~]# ps aux | grep "rpc\."
rpcuser   4220  0.0  0.3  44484  1720 ?        Ss   07:21   0:00 /usr/sbin/rpc.statd --no-notify -p 32765 -o 32766
root      4325  0.0  0.0  17124   392 ?        Ss   07:21   0:00 /usr/sbin/rpc.idmapd
root      4326  0.0  0.2  42720   952 ?        Ss   07:21   0:00 /usr/sbin/rpc.mountd -p 32767

[root@server-centos-71 ~]# cat /run/sysconfig/nfs-utils
RPCNFSDARGS=" 8"
RPCMOUNTDARGS="-p 32767"
STATDARGS="-p 32765 -o 32766"
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
GSSDARGS=""
SVCGSSDARGS=""
BLKMAPDARGS=""
GSS_USE_PROXY=""

[root@server-centos-71 ~]# cat /etc/sysconfig/nfs
# Generated by Chef for server-centos-71# Local modifications will be overwritten.
# Rendered RHEL template variant
STATD_PORT="32765"
STATD_OUTGOING_PORT="32766"
STATDARG="-p 32765 -o 32766"
MOUNTD_PORT="32767"
RPCMOUNTDOPTS="-p 32767"
LOCKD_UDPPORT="32768"
LOCKD_TCPPORT="32768"
RQUOTAD_PORT="32769"
RQUOTAD="no"
RPCNFSDCOUNT="8"

[root@server-centos-71 ~]# rpm -qa | grep nfs-utils
nfs-utils-1.3.0-0.8.el7.x86_64

`server-centos-72`

This suite doesn't exist yet, so add centos-7.2 platform to .kitchen.yml and try to converge it. There will be nfs-utils-1.3.0-0.21.el7.x86_64 installed, but rpc-statd will be misconfigured:

[root@server-centos-72 ~]# ps aux | grep "rpc\."
rpcuser   4234  0.0  0.3  44516  1728 ?        Ss   10:14   0:00 /usr/sbin/rpc.statd --no-notify
root      4343  0.0  0.0  17148   396 ?        Ss   10:14   0:00 /usr/sbin/rpc.idmapd
root      4344  0.0  0.1  44852   968 ?        Ss   10:14   0:00 /usr/sbin/rpc.mountd

[root@server-centos-72 ~]# cat /run/sysconfig/nfs-utils
RPCNFSDARGS=" 8"
RPCMOUNTDARGS=""
STATDARGS=""
SMNOTIFYARGS=""
RPCIDMAPDARGS=""
GSSDARGS=""
SVCGSSDARGS=""
BLKMAPDARGS=""
GSS_USE_PROXY="yes"

[root@server-centos-72 ~]# cat /etc/sysconfig/nfs
# Generated by Chef for server-centos-72# Local modifications will be overwritten.
# Rendered RHEL template variant
STATD_PORT="32765"
STATD_OUTGOING_PORT="32766"
STATDARG="-p 32765 -o 32766"
MOUNTD_PORT="32767"
RPCMOUNTDOPTS="-p 32767"
LOCKD_UDPPORT="32768"
LOCKD_TCPPORT="32768"
RQUOTAD_PORT="32769"
RQUOTAD="no"
RPCNFSDCOUNT="8"

[root@server-centos-72 ~]# rpm -qa | grep nfs-utils
nfs-utils-1.3.0-0.21.el7.x86_64

As a result, kitchen verify server-centos-72 will fail.
It could be fixed manually by running:

systemctl restart  nfs-config.service
systemctl restart  nfs-server.service
systemctl restart  rpc-statd.service

The first command re-generates /run/sysconfig/nfs-utils and puts the sufficient values for static ports there. Other two commands restart the appropriate services.

Does anybody have a suggestion how it should be handled on the cookbook side?

Recipe "default" in v2.2.1 failed to run on CentOS 6.6

I can not figure out what really happens, but I suppose that it is due to provider Chef::Resource::Service:

================================================================================
           Error executing action `start` on resource 'service[portmap]'
           ================================================================================

           ArgumentError
           -------------
           wrong number of arguments (0 for 1..3)

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/nfs/recipes/_common.rb

            43:   service component do
            44:     service_name node['nfs']['service'][component]
            45:     pattern node['nfs']['service'][component]
            46:     provider node['nfs']['service_provider'][component]
            47:     action [:start, :enable]
            48:     supports :status => true
            49:   end
            50: end

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/nfs/recipes/_common.rb:43:in `block in from_file'

           service("portmap") do
             provider Chef::Resource::Service
             action [:start, :enable]
             supports {:status=>true}
             retries 0
             retry_delay 2
             default_guard_interpreter :default
             service_name "rpcbind"
             pattern "rpcbind"
             declared_type :service
             cookbook_name "nfs"
             recipe_name "_common"
           end

       Running handlers:
       [2015-07-01T16:31:23+03:00] ERROR: Running exception handlers
       Running handlers complete
       [2015-07-01T16:31:23+03:00] ERROR: Exception handlers complete
       Chef Client failed. 30 resources updated in 91.527318639 seconds
       [2015-07-01T16:31:24+03:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
       [2015-07-01T16:31:24+03:00] ERROR: service[portmap] (nfs::_common line 43) had an error: ArgumentError: wrong number of arguments (0 for 1..3)
       [2015-07-01T16:31:24+03:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

No such file or directory - exportfs

         Error executing action `run` on resource 'execute[exportfs]'
      
         Errno::ENOENT
         -------------
         No such file or directory - exportfs
         
         Cookbook Trace:
         ---------------
         /tmp/kitchen/cache/cookbooks/nfs/providers/export.rb:73:in `block in class_from_file'
         
         Resource Declaration:
         ---------------------
         # In /tmp/kitchen/cache/cookbooks/nfs/providers/export.rb
         
   43:     execute 'exportfs' do
   44:       command 'exportfs -ar'
   45:       action :nothing
   46:     end
   47:

Platform: centos-7.2 (run in test-kitchen)

stacktrace.log

Deprecated features used

With chef-12 the following warnings are reported because /etc/sysconfig/nfs is
listed in server and client templates

Deprecated features used!
  Cloning resource attributes for template[/etc/sysconfig/nfs] from prior resource (CHEF-3694)
Previous template[/etc/sysconfig/nfs]: /var/chef/cache/cookbooks/nfs/recipes/_common.rb:36:in `block in from_file'
Current  template[/etc/sysconfig/nfs]: /var/chef/cache/cookbooks/nfs/recipes/server.rb:26:in `from_file' at 1 location:
    - /var/chef/cache/cookbooks/nfs/recipes/server.rb:26:in `from_file'

/sbin/start rpcbind returned 1, expected 0

This probably has to do with the fact that I'm running this on Ubuntu Lucid (10.04). I tried playing around with the service resource init_command but no love there. Any advice here would be much appreciated. Thanks!

nfs cookbook version 2.0.0
Chef: 11.14.2
Ubuntu 10.04

https://gist.github.com/luntzel/4e9dcb0b2137266806ce

_idmap recipe on debian also installs nfs-kernel-server

when selecting nfs::client4 for NFSv4 client support on ubuntu/debian this recipe also runs the _idmap recipe (which makes sense to me, idmapd is needed) but in this line:

https://github.com/atomic-penguin/cookbook-nfs/blob/master/recipes/_idmap.rb#L22

nfs-kernel-server is also installed, which should only be required for the nfs server, not the client. Perhaps I'm missing something, but I've been running an NFSv4 setup for quite some time on ubuntu without nfs-kernel-server installed on the clients. Perhaps this should be removed, maybe the reasoning clarified or at least the installation of this package abstracted to an attribute so someone can opt of out nfs-kernel-server installation on their nfs client.

Thanks for the cookbook!

Can`t specify the nfs4 nlockmgr port in CentOS 7.5

Hi , everybody,
I have met a problem today.
I can not specify the nfs4 nlockmgr port in CentOS 7.5 .
I have searched a lot , but the “LOCKD_TCPPORT” and “LOCKD_UDPPORT” field does not exist in the nfs4 config file "/etc/sysconfig/nfs"
I tried to add them and reboot the server ,it didnt take effected. Related infomation is as follows . Lets talk and resolve together.
THX Everybody.
My email is admin#bluenoob.com

[root@~]# uname -a
Linux  3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May 21 23:36:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@~]# rpm -qa | grep nfs-utils
nfs-utils-1.3.0-0.54.el7.x86_64

[root@~]# cat /etc/sysconfig/nfs

#
#
# To set lockd kernel module parameters please see
#  /etc/modprobe.d/lockd.conf
#
# Optional arguments passed to rpc.nfsd. See rpc.nfsd(8)
RPCNFSDARGS=""
# Number of nfs server processes to be started.
# The default is 8.
#RPCNFSDCOUNT=16
#
# Set V4 grace period in seconds
#NFSD_V4_GRACE=90
#
# Set V4 lease period in seconds
#NFSD_V4_LEASE=90
#
# Optional arguments passed to rpc.mountd. See rpc.mountd(8)
RPCMOUNTDOPTS=""
# Port rpc.mountd should listen on.
MOUNTD_PORT=892
#
# Optional arguments passed to rpc.statd. See rpc.statd(8)
STATDARG=""
# Port rpc.statd should listen on.
STATD_PORT=662
# Outgoing port statd should used. The default is port
# is random
STATD_OUTGOING_PORT=2020
# Specify callout program
#STATD_HA_CALLOUT="/usr/local/bin/foo"
#
#
# Optional arguments passed to sm-notify. See sm-notify(8)
SMNOTIFYARGS=""
#
# Optional arguments passed to rpc.idmapd. See rpc.idmapd(8)
RPCIDMAPDARGS=""
#
# Optional arguments passed to rpc.gssd. See rpc.gssd(8)
# Note: The rpc-gssd service will not start unless the
#       file /etc/krb5.keytab exists. If an alternate
#       keytab is needed, that separate keytab file
#       location may be defined in the rpc-gssd.service's
#       systemd unit file under the ConditionPathExists
#       parameter
RPCGSSDARGS=""
#
# Enable usage of gssproxy. See gssproxy-mech(8).
GSS_USE_PROXY="yes"
#
# Optional arguments passed to blkmapd. See blkmapd(8)
BLKMAPDARGS=""

LOCKD_TCPPORT=4004
LOCKD_UDPPORT=4005

[root@ ~]# rpcinfo -p
   program vers proto   port  service
    100000    4   tcp    111  portmapper
    100000    3   tcp    111  portmapper
    100000    2   tcp    111  portmapper
    100000    4   udp    111  portmapper
    100000    3   udp    111  portmapper
    100000    2   udp    111  portmapper
    100005    1   udp    892  mountd
    100005    1   tcp    892  mountd
    100005    2   udp    892  mountd
    100005    2   tcp    892  mountd
    100005    3   udp    892  mountd
    100005    3   tcp    892  mountd
    100024    1   udp    662  status
    100024    1   tcp    662  status
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    3   tcp   2049  nfs_acl
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    3   udp   2049  nfs_acl
    100021    1   udp  48769  nlockmgr
    100021    3   udp  48769  nlockmgr
    100021    4   udp  48769  nlockmgr
    100021    1   tcp  38516  nlockmgr
    100021    3   tcp  38516  nlockmgr
    100021    4   tcp  38516  nlockmgr

config.service not found on raspbian

Service 'config' (config.service) can not be found on Raspbian and therefore started, causing whole setup to constantly fail on that OS. The reason is that Rasbian has that service called nfs-config (like Ubuntu does). But Raspbian does not match a default['nfs']['service']['config'] check because its 'platform' attribute is not 'debian', but 'raspbian' (platform_family is 'debian' instead).

As a workaround, attributes/default.rb sould be modified somehow, for example:

--- a/chef-repo/cookbooks/nfs/attributes/default.rb
+++ b/chef-repo/cookbooks/nfs/attributes/default.rb
@@ -47,6 +47,8 @@ default['nfs']['packages'] = if node['platform_family'] == 'debian'
 default['nfs']['service']['config'] = if (node['platform'] == 'debian' && node['platform_version'].to_i >= 10) ||
                                          (node['platform'] == 'ubuntu' && node['platform_version'].to_i >= 15)
                                         'nfs-config.service'
+                                      else
+                                        'nfs-config.service'
                                       end

The latest version is not on community.opscode.com

Hi,

This cookbook's version on community.opscode.com is 0.2.7, which is the same as this one, according to metadata.rb.

The code is different, though, specifically the portmap and lock services on Debian and Ubuntu systems that are set on attributes/default.rb.

Would it be possible to upload the latest version (and bump it to 0.2.8 or whatever) to community?

Thanks!

Add a license file to the repo

I see that the README states that the code is under the Apache license.

Would you mind adding a copy of the full license text to the repo to clarify?

Thanks!

Add support for Amazon

Amazon detects as rhel, but the platform version isn't sufficient. It behaves like RHEL 6.

Debian 8 service error

It seems the cookbook lacks definition for debian 8 and it's systemD.

service[idmap] action restart

       ================================================================================
       Error executing action `restart` on resource 'service[idmap]'
       ================================================================================

       Mixlib::ShellOut::ShellCommandFailed
       ------------------------------------
       Expected process to exit with [0], but received '1'
       ---- Begin output of /etc/init.d/nfs-common start ----
       STDOUT: Starting nfs-common (via systemctl): nfs-common.service failed!
       STDERR: Job for nfs-common.service failed. See 'systemctl status nfs-common.service' and 'journalctl -xn' for details.
       ---- End output of /etc/init.d/nfs-common start ----
       Ran /etc/init.d/nfs-common start returned 1

       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cache/cookbooks/nfs/recipes/_idmap.rb

        29: service 'idmap' do
        30:   service_name node['nfs']['service']['idmap']
        31:   provider node['nfs']['service_provider']['idmap'] if node['platform'] == 'ubuntu'
        32:   action [:start, :enable]
        33:   supports :status => true
        34: end

       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cache/cookbooks/nfs/recipes/_idmap.rb:29:in `from_file'

       service("idmap") do
         action [:start, :enable]
         supports {:status=>true}
         retries 0
         retry_delay 2
         default_guard_interpreter :default
         service_name "nfs-common"
         pattern "idmap"
         declared_type :service
         cookbook_name "nfs"
         recipe_name "_idmap"
       end

Invalid /etc/exports generated as of v2.4.0

Hello @atomic-penguin, bug #96 still applies as of v2.4.0 of this cookbook.

The last time, you pulled v2.3.3 release from the supermarket, but the issue is still present on master.
I can provide a hand with testing if needed. For now, I stay on v2.3.1.

nfs_export provider fails if /etc/exports is missing

[Mon, 15 Apr 2013 16:26:14 -0400] INFO: Processing append_if_no_line[export /media/lgmedia] action edit (/var/cache/chef/cookbooks/nfs/providers/export.rb line 49)
[Mon, 15 Apr 2013 16:26:14 -0400] ERROR: Running exception handlers
[Mon, 15 Apr 2013 16:26:14 -0400] FATAL: Saving node information to /var/cache/chef/failed-run-data.json
[Mon, 15 Apr 2013 16:26:14 -0400] ERROR: Exception handlers complete
[Mon, 15 Apr 2013 16:26:14 -0400] ERROR: ArgumentError: nfs_export[/media/lgmedia](lg_nfs::default line 12) had an error: ArgumentError: append_if_no_line[export /media/lgmedia](/var/cache/chef/cookbooks/nfs/p
roviders/export.rb line 49) had an error: ArgumentError: File doesn't exist
[Mon, 15 Apr 2013 16:26:14 -0400] FATAL: Stacktrace dumped to /var/cache/chef/chef-stacktrace.out
[Mon, 15 Apr 2013 16:26:14 -0400] ERROR: Sleeping for 1800 seconds before trying again

Is this cookbook abandoned?

It appears that this cookbook is getting very little attention and issues/PRs are not reviewed?

Invalid /etc/exports generated since v2.3.3

I have a chef recipe which declares several NFS exports.

Before v2.3.3, my node would converge just fine.
After v2.3.3, the chef-run fails with the following message:

==> backends:     Mixlib::ShellOut::ShellCommandFailed
==> backends:     ------------------------------------
==> backends:     nfs_export[/srv/nfs-shared-2] (/tmp/vagrant-cache/chef/cookbooks/pm_environment/libraries/openshift3_nfs_export.rb line 32) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[exportfs] (/tmp/vagrant-cache/chef/cookbooks/nfs/providers/export.rb line 43) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
==> backends:     ---- Begin output of exportfs -ar ----
==> backends:     STDOUT: 
==> backends:     STDERR: exportfs: /etc/exports:1: syntax error: bad option list
==> backends:     ---- End output of exportfs -ar ----
==> backends:     Ran exportfs -ar returned 1
==> backends:     
==> backends:     Cookbook Trace:

Here is the generated /etc/exports on the node:

[root@backends ~]# cat /etc/exports
/srv/nfs-shared-1 192.168.33.0/24(rw,sync,no_root_squash,no_wdelay)/srv/nfs-shared-2 192.168.33.0/24(rw,sync,no_root_squash,no_wdelay)

Note that the two exports are incorrectly placed on the same line, instead of being placed on two different lines.

I believe that this regression is the consequence of #95, which was recently merged.

As a workaround, I will stick to v2.3.1 until this issue is fixed.

Error executing action `restart` on resource 'service[lock]'

Environment: Ubuntu 12.04

It seems to happen because statd is already running. The line which checked whether the service is running was commented out in this commit (_common.rb). Can this be uncommented?

On commandline

$ sudo /sbin/start statd
start: Job is already running: statd
$ echo $?
1

Chef Run

     * service[lock] action restart

       ================================================================================
       Error executing action `restart` on resource 'service[lock]'
       ================================================================================

       Mixlib::ShellOut::ShellCommandFailed
       ------------------------------------
       Expected process to exit with [0], but received '1'
       ---- Begin output of /sbin/start statd ----
       STDOUT: 
       STDERR: start: Job is already running: statd
       ---- End output of /sbin/start statd ----
       Ran /sbin/start statd returned 1

       Resource Declaration:
       ---------------------
       # In /vagrant/cache/cookbooks/nfs/recipes/_common.rb

        46:   service component do
        47:     service_name node['nfs']['service'][component]
        48:     provider node['nfs']['service_provider'][component] if node['platform_family'] == 'debian'
        49:     # not_if "service #{component} status | grep -q running"
        50:     action [:start, :enable]
        51:     # supports :status => true
        52:   end
        53: end

       Compiled Resource:
       ------------------
       # Declared in /vagrant/cache/cookbooks/nfs/recipes/_common.rb:46:in `block in from_file'

       service("lock") do
         provider Chef::Provider::Service::Upstart
         action [:start, :enable]
         supports {:restart=>false, :reload=>false, :status=>false}
         retries 0
         retry_delay 2
         default_guard_interpreter :default
         service_name "statd"
         pattern "lock"
         declared_type :service
         cookbook_name "nfs"
         recipe_name "_common"
       end

This seems to happen intermittently. Most of the times, service[lock] action restart runs successfully.

     * service[lock] action restart
   - restart service service[lock]
     * template[/etc/modprobe.d/lockd.conf] action create



   2016-05-26 16:36:39.691831144 -0700




   - change mode from '' to '0644'
     * service[portmap] action restart
       - restart service service[portmap]

       - restart service service[lock]
    (up to date)
     * service[portmap] action enable (up to date)
     * service[lock] action start (up to date)
     * service[lock] action enable (up to date)

Error executing action 'start' on resource portmap

Centos v.6.6
Chef: 12.4.1

I also noticed this issue on Vagrant/Virtualbox which the workaround was originally to only include NFS for ec2 instances, but now I'm seeing the same issue on cent6.6 with no modifications to our AMI's or cookbooks.

service[portmap] action start

Error executing action start on resource 'service[portmap]'

ArgumentError

wrong number of arguments (0 for 1..3)

Resource Declaration:

In /var/cache/chef/cookbooks/nfs/recipes/_common.rb

43: service component do
44: service_name node['nfs']['service'][component]
45: pattern node['nfs']['service'][component]
46: provider node['nfs']['service_provider'][component]
47: action [:start, :enable]
48: supports :status => true
49: end
50: end

Compiled Resource:

Declared in /var/cache/chef/cookbooks/nfs/recipes/_common.rb:43:in `block in from_file'

service("portmap") do
provider Chef::Resource::Service
action [:start, :enable]
supports {:status=>true}
retries 0
retry_delay 2
default_guard_interpreter :default
service_name "rpcbind"
pattern "rpcbind"
declared_type :service
cookbook_name "nfs"
recipe_name "_common"
end

Would really appreciate it if anyone had a workaround for this as it's totally blocking us from a scheduled release.

Cookbook failing due to new version of sysctl cookbook

On 2017-08-05 version 0.10.0 of cookbook sysctl was released.
That new release seems to have introduced a change that breaks this cookbook.
The error looks like this:

================================================================================
Recipe Compile Error in /var/folders/7q/6p5yh0xx4_ldmv2g4b9n12300000gp/T/d20170807-3398-11ovc8r/cookbooks/nfs/attributes/default.rb
================================================================================

Chef::Exceptions::AttributeNotFound
-----------------------------------
could not find filename for attribute default in cookbook sysctl

Cookbook Trace:
---------------
  /var/folders/7q/6p5yh0xx4_ldmv2g4b9n12300000gp/T/d20170807-3398-11ovc8r/cookbooks/nfs/attributes/default.rb:20:in `from_file'

Relevant File Content:
----------------------
/var/folders/7q/6p5yh0xx4_ldmv2g4b9n12300000gp/T/d20170807-3398-11ovc8r/cookbooks/nfs/attributes/default.rb:

 13:  # Unless required by applicable law or agreed to in writing, software
 14:  # distributed under the License is distributed on an 'AS IS' BASIS,
 15:  # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 16:  # See the License for the specific language governing permissions and
 17:  # limitations under the License.
 18:  #
 19:
 20>> include_attribute 'sysctl'
 21:
 22:  # Allowing Version 2, 3 and 4 of NFS to be enabled or disabled.
 23:  # Default behavior, defer to protocol level(s) supported by kernel.
 24:  default['nfs']['v2'] = nil
 25:  default['nfs']['v3'] = nil
 26:  default['nfs']['v4'] = nil
 27:
 28:  # rquotad needed?
 29:  default['nfs']['rquotad'] = 'no'

The error is reproducable by running the specs.

Amazon Linux breaks after RHEL 7 updates

Hi,

Due to changes in the nfs cookbook after merging in #57 Amazon Linux is now non-functional out of the box (due to attributes) and at all (due to recipes).

The main culprit is the of logic checks like this:
node['platform_family'] == 'rhel' && node['platform_version'].to_i >= 7

Most versions of Amazon Linux are a fork of RHEL 6, but the versions are based on years (e.g. the latest is 2015.03), so always are >= 7

For attributes this in manageable but for recipes this is breaking, specifically the server recipe.

Blocks which check for rhel version >=7 need to exclude node['platform'] = 'amazon'

2.1.0 -> 2.2.1 breaks on centos 6.6 with chef 12.3.0

i just tried to upgrade and was forced to roll back. see below...

  * service[portmap] action start[2015-06-30T11:55:18-04:00] INFO: Processing service[portmap] action start (nfs::_common line 43)


    ================================================================================
    Error executing action `start` on resource 'service[portmap]'
    ================================================================================

    NoMethodError
    -------------
    undefined method `action=' for Chef::Resource::Service

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/nfs/recipes/_common.rb

     43:   service component do
     44:     service_name node['nfs']['service'][component]
     45:     pattern node['nfs']['service'][component]
     46:     provider node['nfs']['service_provider'][component]
     47:     action [:start, :enable]
     48:     supports :status => true
     49:   end
     50: end

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/nfs/recipes/_common.rb:43:in `block in from_file'

    service("portmap") do
      provider Chef::Resource::Service
      action [:start, :enable]
      supports {:status=>true}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      service_name "rpcbind"
      pattern "rpcbind"
      declared_type :service
      cookbook_name "nfs"
      recipe_name "_common"
    end

Support Ubuntu 16.04 LTS

First off, great cookbook! While upgrading to 16.04 I ran into a couple issues though:

Systemd needs to be selected as the provider for Ubuntu 16.04:

================================================================================
Error executing action `start` on resource 'service[portmap]'
================================================================================

Errno::ENOENT
-------------
No such file or directory - /sbin/status

I was able to hack around this with:

node.default['nfs']['service_provider'] = Hash.new { |h, k| h[k] = Chef::Provider::Service::Systemd }

The statd service was renamed to rpc-statd:

================================================================================
Error executing action `start` on resource 'service[lock]'
================================================================================

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '5'
---- Begin output of /bin/systemctl --system start statd ----
STDOUT: 
STDERR: Failed to start statd.service: Unit statd.service not found.
---- End output of /bin/systemctl --system start statd ----
Ran /bin/systemctl --system start statd returned 5

I was able to hack around this with:

node.default['nfs']['service']['lock'] = 'rpc-statd'

Other than that, everything else works fine. I hope we can get a real fix for this soon. 😄

idmapd not starting on SLES 11 SP3

ERROR: service[idmap](nfs::_idmap line 31) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '6'
---- Begin output of /sbin/service nfs start ----
STDOUT: Not starting NFS client services - no NFS found in /etc/fstab:
STDERR: ..unused
---- End output of /sbin/service nfs start ----
Ran /sbin/service nfs start returned 6

NFS service is not finding any NFS mount points in /etc/fstab, it consider NFS being useless, and exit with error.
However, if adding 'NFS_START_SERVICES=yes' to '/etc/sysconfig/nfs' file, service starts successfully.

This is the way how init script is written for SLES 11 SP 3.

Can you add the line, please?
To /etc/sysconfig/nfs, 'suse' section
NFS_START_SERVICES=yes

Thanks,
Vladimir

ERROR: Option network must be one of: required! You passed...

I am getting the following issue:
9: nfs_export "/var/www" do
10>> network '*'
11: writeable true
12: anonuser node['lamp']['share']['user']
13: anongroup node['lamp']['share']['group']
14: sync true

    16:  end

...

[2015-10-10T11:41:47+00:00] ERROR: Option network must be one of: required! You passed "*".

Please merge this pull request:
#67

Thanks.

Question: firewall rules

Hi.

Does anybody have a recommended way to handle firewall issues with this recipe? It seems that there are a lot of different options out there (firewalld and iptables for example) and on top of that I'm not a 100% sure what needs to be opened up exactly after this recipe has run.

Currently I'm trying out something like this for iptables (depends on the simple_iptables cookbook):

simple_iptables_rule "db-port" do
  rule ["--proto tcp --dport #{node.nfs.port.statd}", "--proto udp --dport #{node.nfs.port.statd}", 
    "--proto tcp --dport #{node.nfs.port.mountd}", "--proto udp --dport #{node.nfs.port.mountd}",
    "--proto tcp --dport #{node.nfs.port.lockd}", "--proto udp --dport #{node.nfs.port.lockd}",
    "--proto tcp --dport #{node.nfs.port.rquotad}", "--proto udp --dport #{node.nfs.port.rquotad}"]
  jump "ACCEPT"
end

And for firewalld I'm trying this:

firewalld_service 'nfs' do
    action :add
    zone   'public'
end

Then there is ufw and probably many others that could possibly be running. Please note that the code above has not been tested properly.

But my question is whether something like this should be a part of this cookbook? I'm not sure if there is a good way to find out 1) which firewall is running on a server and 2) whether that firewall is actually running or disabled. Any pointers on that would be appreciated.

Sorry about the open ended question here, I'm mostly just wondering whether anybody has experience worrying about firewall issues with NFS using this cookbook.

NFS recipe doesn't work out of the box on CentOS 7

I need to add the following attributes if I want the NFS cookbook to work properly on CentOS 7:

if node.platform == "centos" && node.platform_version.to_i == 7
    default['nfs']['service']['lock'] = 'nfs-lock'
    default['nfs']['service']['server'] = 'nfs-server'
    default['nfs']['service']['idmap'] = 'nfs-idmap'
end

It would be great if this was handled transparently by the coobook.

RHEL/CentOS7 broke

The updates for RHEL/CentOS 7 are not evaluating the platform correctly. Specifically looking at https://github.com/atomic-penguin/cookbook-nfs/blob/master/recipes/server.rb#L34 it is not correctly detecting CentOS/RHEL 7.

[centos@ip-192-168-0-225 ~]$ cat /etc/system-release
CentOS Linux release 7.1.1503 (Core)
[centos@ip-192-168-0-225 ~]$ chef-shell
loading configuration: none (standalone session)
Session type: standalone
Loading..done.

This is the chef-shell.
 Chef Version: 12.4.3
 http://www.chef.io/
 http://docs.chef.io/

run `help' for help, `exit' or ^D to quit.

Ohai2u [email protected]!
chef (12.4.3)> !node['platform'] == 'amazon'
 => false
chef (12.4.3)> node['platform'] != 'amazon'
 => true
chef (12.4.3)> node['platform_family'] == 'rhel' && node['platform_version'].to_f >= 7.0 && !node['platform'] == 'amazon'
 => false
chef (12.4.3)> node['platform_family'] == 'rhel' && node['platform_version'].to_f >= 7.0 && node['platform'] != 'amazon'
 => true
chef (12.4.3)>

the v2.2.7 version craches chef 11

here is the error in chef stackstrace:
NoMethodError: undefined method source_url' for #<Chef::Cookbook::Metadata:0x00000002845bc8> ....../nfs/metadata.rb:8:infrom_file'

According to Chef issue chef/chef#2937, the responsibility of the cookbook maintainer to provide backcompat if they're adopting features. They can use if respond_to?(:source_url) or if defined? source_url instead.

need to update line version which supported chef 12

Hi team,
we are using NFS cookbook as a dependency in our cookbook , it downloading during runtime but we are supporting chef 12 but NFS depends Line latest version which support Chef 13
how I can change the line version or
could you please update acoordingly

Cannot find a provider for service on redhat version 6.6

Im getting the following recipe compile error:
ERROR: Cannot find a provider for service on redhat version 6.6

caused by this line in attributes file

default['nfs']['service_provider']['lock'] = Chef::Platform.find_provider_for_node node, :service

Doesn't work on Ubuntu 13.10

Ubuntu has changed a few services around again and I cannot get it to work with the new version.

Race condition on Centos7 nfs-server

Seeing a pretty regular race condition since the latest updates for CentOS 7. Basically the cookbook is trying to set sysctl values before the nfs modules have been loaded, so they don't exist.

`Recipe: nfs::server
* sysctl_param[fs.nfs.nlm_tcpport] action apply

     * execute[sysctl[fs.nfs.nlm_tcpport]] action run

       ================================================================================
       Error executing action `run` on resource 'execute[sysctl[fs.nfs.nlm_tcpport]]'
       ================================================================================

       Mixlib::ShellOut::ShellCommandFailed
       ------------------------------------
       Expected process to exit with [0], but received '255'
       ---- Begin output of sysctl -w "fs.nfs.nlm_tcpport=32768" ----
       STDOUT: 
       STDERR: sysctl: cannot stat /proc/sys/fs/nfs/nlm_tcpport: No such file or directory
       ---- End output of sysctl -w "fs.nfs.nlm_tcpport=32768" ----
       Ran sysctl -w "fs.nfs.nlm_tcpport=32768" returned 255

       Cookbook Trace:
       ---------------
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:78:in `run_action'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block (2 levels) in converge'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `each'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:106:in `block in converge'
       /tmp/kitchen/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:105:in `converge'

       Resource Declaration:
       ---------------------
       # In /tmp/kitchen/cache/cookbooks/sysctl/providers/param.rb

        21:     execute "sysctl[#{new_resource.key}]" do
        22:       command "sysctl -w \"#{new_resource.key}=#{new_resource.value}\""
        23:       notifies :run, 'ruby_block[save-sysctl-params]', :delayed
        24:     end
        25:     new_resource.updated_by_last_action(true)

       Compiled Resource:
       ------------------
       # Declared in /tmp/kitchen/cache/cookbooks/sysctl/providers/param.rb:21:in `block in class_from_file'

       execute("sysctl[fs.nfs.nlm_tcpport]") do
         action [:run]
         retries 0
         retry_delay 2
         default_guard_interpreter :execute
         command "sysctl -w \"fs.nfs.nlm_tcpport=32768\""
         backup 5
         returns 0
         declared_type :execute
         cookbook_name "nfs"
       end

       Platform:
       ---------
       x86_64-linux

   Recipe: openssh::default
     * service[ssh] action restart
       - restart service service[ssh]
   Recipe: nfs::server
     * service[nfs-server] action restart
       - restart service service[nfs-server]

   Running handlers:
   [2016-08-31T23:44:36+00:00] ERROR: Running exception handlers
   Running handlers complete
   [2016-08-31T23:44:36+00:00] ERROR: Exception handlers complete
   Chef Client failed. 65 resources updated in 06 minutes 12 seconds
   [2016-08-31T23:44:36+00:00] FATAL: Stacktrace dumped to /tmp/kitchen/cache/chef-stacktrace.out
   [2016-08-31T23:44:36+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
   [2016-08-31T23:44:36+00:00] ERROR: execute[sysctl[fs.nfs.nlm_tcpport]] (/tmp/kitchen/cache/cookbooks/sysctl/providers/param.rb line 21) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '255'
   ---- Begin output of sysctl -w "fs.nfs.nlm_tcpport=32768" ----
   STDOUT: 
   STDERR: sysctl: cannot stat /proc/sys/fs/nfs/nlm_tcpport: No such file or directory
   ---- End output of sysctl -w "fs.nfs.nlm_tcpport=32768" ----
   Ran sysctl -w "fs.nfs.nlm_tcpport=32768" returned 255
   [2016-08-31T23:44:36+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)`

Multiple export LWRP calls results in broken /etc/exports - but only if exports is empty or non-existent

My recipe calls the export LWRP twice, which results in a broken /etc/exports - but only if exports is empty or non-existent. If there is anything there before the converge, it appends lines correctly.

LWRP calls from recipe

nfs_export "/tmp/dir1" do
  network "10.0.0.0/8"
  writeable false
  sync false
end

nfs_export "/tmp/dir2" do
  network "10.0.0.0/8"
  writeable false
  sync false
end

/etc/exports content

/tmp/dir1 10.0.0.0/8(ro,async,root_squash)/tmp/dir2 10.0.0.0/8(ro,async,root_squash)

Editing /etc/exports so it contains something (line with foobar on it) beforehand, then running, results in

foobar
/tmp/dir1 10.0.0.0/8(ro,async,root_squash)
/tmp/dir2 10.0.0.0/8(ro,async,root_squash)

The culprit seems to be providers.rb:42 which doesn't append a newline, making the next call to the LWRP append at the end of the first line.

CentOS 6, Chef 10.26.0

nfs-export doesn't notify other resources

It seems that the use of a sub-context to run the provider doesn't allow notifications to propagate to other resources.

Recipe nfs::_common is restarting nfs-client.target service with every chef-client run on RHEL 8 servers

On RHEL 8 servers, recipe nfs::_common is restarting nfs-client.target service with every chef-client run.
This issue is reproducible with 3.0.0 version of cookbook as well.

[root@app-server-A ~]$ cat /etc/redhat-release 
Red Hat Enterprise Linux release 8.4 (Ootpa)
[root@app-server-A ~]

[root@app-server-A ~]$ date
Fri Aug 13 09:11:38 UTC 2021
[root@app-server-A ~]$ 

[root@app-server-A ~]$ ls -ltr /etc/sysconfig/nfs*
-rw-r--r--. 1 root root 349 Aug 13 09:10 /etc/sysconfig/nfs.rpmsave
[root@app-server-A ~]$
[root@app-server-A ~]$ ls -ltr /etc/nfs*
-rw-r--r--. 1 root root 3606 Jan 20  2021 /etc/nfsmount.conf
-rw-r--r--. 1 root root 1188 Aug 13 09:10 /etc/nfs.conf.rpmsave
-rw-r--r--. 1 root root 1188 Aug 13 09:10 /etc/nfs.conf
[root@app-server-A ~]$

[root@app-server-A ~]$ chef-client -o recipe[nfs::_common]
Starting Chef Client, version 14.15.6
[2021-08-13T08:54:20+00:00] WARN: Run List override has been provided.
[2021-08-13T08:54:20+00:00] WARN: Original Run List: [role[global], role[monitoring]]
[2021-08-13T08:54:20+00:00] WARN: Overridden Run List: [recipe[nfs::_common]]
resolving cookbooks for run list: ["nfs::_common"]
Synchronizing Cookbooks:
  - nfs (2.6.4)
  - line (2.9.3)
Installing Cookbook Gems:
Compiling Cookbooks...
Converging 6 resources
Recipe: nfs::_common
  * dnf_package[nfs-utils] action install (up to date)
  * dnf_package[rpcbind] action install (up to date)
  * directory[/etc/sysconfig] action create (skipped due to only_if)
  * template[/etc/sysconfig/nfs] action create
    - create new file /etc/sysconfig/nfs
    - update content in file /etc/sysconfig/nfs from none to 7b5f09
    --- /etc/sysconfig/nfs	2021-08-13 08:54:25.975261236 +0000
    +++ /etc/sysconfig/.chef-nfs20210813-2380443-176dink	2021-08-13 08:54:25.975261236 +0000
    @@ -1 +1,14 @@
    +# Generated by Chef for app-server-A# Local modifications will be overwritten.
    +# Rendered RHEL template variant
    +STATD_PORT="32765"
    +STATD_OUTGOING_PORT="32766"
    +STATDARG="-p 32765 -o 32766"
    +MOUNTD_PORT="32767"
    +RPCMOUNTDOPTS="-p 32767"
    +LOCKD_UDPPORT="32768"
    +LOCKD_TCPPORT="32768"
    +RQUOTAD_PORT="32769"
    +RQUOTAD="no"
    +RPCNFSDCOUNT="8"
    +
    - change mode from '' to '0644'
    - restore selinux security context
  * service[nfs-client.target] action restart
    - restart service service[nfs-client.target]
  * template[/etc/modprobe.d/lockd.conf] action create (up to date)
  * service[nfs-client.target] action start (up to date)
  * service[nfs-client.target] action enable (up to date)
[2021-08-13T08:54:26+00:00] WARN: Skipping final node save because override_runlist was given

Running handlers:
Running handlers complete
Chef Client finished, 2/8 resources updated in 07 seconds
[root@app-server-A ~]$

[root@app-server-A ~]$ ls -ltr /etc/sysconfig/nfs*
-rw-r--r--. 1 root root 349 Aug 13 09:12 /etc/sysconfig/nfs.rpmsave
[root@app-server-A ~]$
[root@app-server-A ~]$ ls -ltr /etc/nfs*
-rw-r--r--. 1 root root 3606 Jan 20  2021 /etc/nfsmount.conf
-rw-r--r--. 1 root root 1188 Aug 13 09:12 /etc/nfs.conf.rpmsave
-rw-r--r--. 1 root root 1188 Aug 13 09:12 /etc/nfs.conf
[root@app-server-A ~]$

Seems like whenever nfs-client.target service restarts /etc/sysconfig/nfs file is getting moved to /etc/sysconfig/nfs.rpmsave.

As per below Red Hat support links /etc/sysconfig/nfs file is deprecated and replaced by /etc/nfs.conf in RHEL 8.
Considerations in adopting RHEL 8
https://access.redhat.com/solutions/3938381

This issue is reproducible on below type of RHEL 8 servers.
1) Physical servers (like HPE Manufacturer)
2) Amazon EC2 instances

This issue is not reproducible on below type of RHEL 8 server (bcoz /etc/sysconfig/nfs persists).
1) VMware servers

$ ls -ltr /etc/sysconfig/nfs*
-rw-r--r-- 1 root root 1679 Jun  8  2020 /etc/sysconfig/nfs.rpmnew
-rw-r--r-- 1 root root  347 Apr 22 22:51 /etc/sysconfig/nfs.rpmsave
-rw-r--r-- 1 root root  347 Aug 13 09:07 /etc/sysconfig/nfs

Metadata incorrect for 5.0.5

🗣️ Foreword

Thank for taking the time to fill this bug report fully. Without it we may not be able to fix the bug, and the issue may be closed without resolution.

👻 Brief Description

A clear and concise description of what the bug is.

Metadata lists 5.0.4 as the version in the 5.0.5 tag https://github.com/sous-chefs/nfs/blob/5.0.5/metadata.rb

🥞 Cookbook version

5.0.5

sous-chefs / nfs Goto Github PK

nfs's Introduction

nfs cookbook

Description

Maintainers

Requirements

Attributes

Usage

nfs_export resource Usage

nfs::default recipe

nfs::client4 recipe

nfs::server recipe

nfs::server4 recipe

nfs::undo recipe

Contributors

Backers

Sponsors

nfs's People

Contributors

Stargazers

Watchers

Forkers

nfs's Issues

Detected dependencies

server-centos-71

server-centos-72

Error executing action start on resource 'service[portmap]'

ArgumentError

Resource Declaration:

In /var/cache/chef/cookbooks/nfs/recipes/_common.rb

Compiled Resource:

Declared in /var/cache/chef/cookbooks/nfs/recipes/_common.rb:43:in `block in from_file'

🗣️ Foreword

👻 Brief Description

🥞 Cookbook version

Recommend Projects

Recommend Topics

Recommend Org

`nfs_export` resource Usage

`server-centos-71`

`server-centos-72`

Error executing action `start` on resource 'service[portmap]'