Welcome to the next part of my little blog entry series about comparing Cfengine 3 with Puppet. In this issue, we will write a Puppet manifest for mounting a NFS share. You can compare it directly to the Cfengine 3 code snippet if you click here. Writing the Puppet code snippet for mounting a NFS […]

Author:

Welcome to the next part of my little blog entry series about comparing Cfengine 3 with Puppet.
In this issue, we will write a Puppet manifest for mounting a NFS share. You can compare it directly to the Cfengine 3 code snippet if you click here.

Writing the Puppet code snippet for mounting a NFS share

mount { "/mnt":
        device  => "localhost:/blubb",
        fstype  => "nfs",
        ensure  => "mounted",
        options => "defaults",
        atboot  => true,
}

Save the file as /etc/puppet/manifests/xenuser_org-004-mounting_a_nfs_share.pp and let it run:

ls -lah --color /mnt
total 8,0K
drwxr-xr-x  2 root root 4,0K 2012-05-10 22:36 .
drwxr-xr-x 23 root root 4,0K 2012-08-20 22:04 ..

puppet apply xenuser_org-004-mounting_a_nfs_share.pp
warning: Could not retrieve fact fqdn
notice: /Stage[main]//Mount[/mnt]/ensure: defined 'ensure' as 'mounted'
notice: /Stage[main]//Mount[/mnt]: Triggered 'refresh' from 1 events
notice: Finished catalog run in 0.18 seconds

As you can see, Puppet claims that the provided NFS share was mounted. Let’s verify that:

grep blubb /proc/mounts
localhost:/blubb/ /mnt nfs4 rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=127.0.0.1,minorversion=0,local_lock=none,addr=127.0.0.1 0 0

ls -lah --color /mnt
total 8,0K
drwxr-xr-x  2 root root 4,0K 2012-05-10 22:36 .
drwxr-xr-x 23 root root 4,0K 2012-08-20 22:04 ..
-rw-r--r--  1 root root    0 2012-05-10 22:36 blobb

Great!

Summary
Mounting the NFS share via Puppet was easy. In addition, Puppet added a new entry in /etc/fstab:

cat /etc/fstab
# HEADER: This file was autogenerated at Sat Jan 19 21:27:19 +0100 2013
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc	/proc	proc	nodev,noexec,nosuid	0	0
# / was on /dev/sda1 during installation
UUID=f89cb605-8324-424f-9a0c-c555e7e0e779	/	ext4,acl	errors=remount-ro	0	1
# swap was on /dev/sda5 during installation
UUID=a66917ea-c89b-4067-80ec-7c13f0a4bd1c	none	swap	sw	0	0
localhost:/blubb	/mnt	nfs	defaults	0	0

There is also a way to add an entry to the fstab file with Cfengine 3 but unfortunately I did not cover it in my blog entry about mounting NFS shares with Cfengine 3.

When comparing both the Cfengine 3 and Puppet snippets with each other, I do not see which configuration management tool does it the more effective or easy way. Both do a good job when looking at the amount of lines you need to write for this purpose. However, one could argue that Puppet does the job a little bit better since you can directly provide the info if the NFS share should be mounted at boots or not (fstab entry).

As usual, you can download today’s Puppet manifest here.

Comments on this entry (2 comments)

Did you like this post? You can share your opinion with us! Simply click here.

reece

thanks for the post. one comment
atboot => “true”,
should be
atboot => true,
otherwise you’ll get an Error: Could not parse for environment production: Could not match  => at …
error

Reply

Hey, thanks for the heads up! Strange that I didn’t see this one when I tested it..

Reply

Add Your Comment

Powered by sweet Captcha


3 × four =