I have many systems that require NFS mounts for production. Rather than have one entry of file{} and mount{} per NFS import, in a *.pp file, I'd rather set up and iterate over an array. Looking at the docs, I'm not quite sure how to do this properly. We have three groups for which I would need this (production, development, test) that each have their own NFS mounts.
Then issue a command to iterate and manage those NFS mounts.
Since these change from time-to-time, and require some pruning... I will be left with "unmanaged" resources (ie: directory mount points) scattered around that I will need to clean up. I read through some tickets for feature requests and got lost in where this is going -- however, to keep the place neat and clean, I'd like to unmanage the mount points and the fstab entries after. The idea of manually doing this from system to system isn't good.
I'm still new-ish to puppet, so any pointers would be appreciated.
#If the state is "unmounted" the mount point 'File' is removed
file { $mount_point:
ensure => $state ? {
"unmounted" => absent,
"absent" => absent,
default => present,
}
}
mount { $mount_point:
ensure => $state,
device => "{$server}:${mount_point}",
}
}
nfs_mount { $production: server => $server, prefix => $prefix}
See the documentation for the Mount type in Puppet and it's ensure parameter for possible values for $state in the define above - it's possible to have entries in /etc/fstab but not actually mounted, which should satisfy your two stage cleanup, or you can just set $state to 'absent' straight away and clean up the both NFS mount and mount point. This means you need to maintain two arrays: one of active mount points and one of decomissioned mounts, however you probably don't need to keep the decomissioned mounts around for ever, once every server has cleaned themselves up they can be removed from the manifest.
> I have many systems that require NFS mounts for production. Rather > than have one entry of file{} and mount{} per NFS import, in a *.pp > file, I'd rather set up and iterate over an array. Looking at the > docs, I'm not quite sure how to do this properly. We have three > groups for which I would need this (production, development, test) > that each have their own NFS mounts.
> Then issue a command to iterate and manage those NFS mounts.
> Since these change from time-to-time, and require some pruning... I > will be left with "unmanaged" resources (ie: directory mount points) > scattered around that I will need to clean up. I read through some > tickets for feature requests and got lost in where this is going -- > however, to keep the place neat and clean, I'd like to unmanage the > mount points and the fstab entries after. The idea of manually doing > this from system to system isn't good.
> I'm still new-ish to puppet, so any pointers would be appreciated.
> Thanks.
> -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group.
> To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/MQ9gniWF4gUJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en.
-- Luke Bigum
Senior Systems Engineer
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
LMAX operates a multilateral trading facility. Authorised and regulated by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.
# Arrays to iterate over, which would be a little longer than this $proddirs = [ "201201", "201202", "201203" ] $testdirs = [ "201201", "201202", "201203" ] $devdirs = [ "201201", "201202", "201203" ]
$nfsopts = "tcp,hard,intr,rw,bg"
By "iterate" I meant to work through a specific array, such as above.
Reading through the Mount part of the docs, I don't believe that "absent" will remove the actual directory point, it says:
"Set it to absent to unmount (if necessary) and remove the filesystem from the fstab"
So I would handle that by running another iteration over an array for each section that would have a routine to make sure it's "absent" and then also rmdir the entry in the filesystem.
I'm not understanding where the below is iterating or over where... as $name would need to be defined somehow.
> nfs_mount { $production: server => $server, prefix => $prefix}
> See the documentation for the Mount type in Puppet and it's ensure > parameter for possible values for $state in the define above - it's > possible to have entries in /etc/fstab but not actually mounted, which > should satisfy your two stage cleanup, or you can just set $state to > 'absent' straight away and clean up the both NFS mount and mount point. > This means you need to maintain two arrays: one of active mount points > and one of decomissioned mounts, however you probably don't need to keep > the decomissioned mounts around for ever, once every server has cleaned > themselves up they can be removed from the manifest.
> On 24/09/12 23:43, Forrie wrote: > > I have many systems that require NFS mounts for production. Rather > > than have one entry of file{} and mount{} per NFS import, in a *.pp > > file, I'd rather set up and iterate over an array. Looking at the > > docs, I'm not quite sure how to do this properly. We have three > > groups for which I would need this (production, development, test) > > that each have their own NFS mounts.
> > Then issue a command to iterate and manage those NFS mounts.
> > Since these change from time-to-time, and require some pruning... I > > will be left with "unmanaged" resources (ie: directory mount points) > > scattered around that I will need to clean up. I read through some > > tickets for feature requests and got lost in where this is going -- > > however, to keep the place neat and clean, I'd like to unmanage the > > mount points and the fstab entries after. The idea of manually doing > > this from system to system isn't good.
> > I'm still new-ish to puppet, so any pointers would be appreciated.
> > Thanks.
> > -- > > You received this message because you are subscribed to the Google > > Groups "Puppet Users" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/puppet-users/-/MQ9gniWF4gUJ. > > To post to this group, send email to puppet...@googlegroups.com<javascript:>.
> > To unsubscribe from this group, send email to > > puppet-users...@googlegroups.com <javascript:>. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en.
> -- > Luke Bigum > Senior Systems Engineer
> Information Systems > Ph: +44 (0) 20 3192 2520 > luke....@lmax.com <javascript:> | http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
> FX and CFDs are leveraged products that can result in losses exceeding > your deposit. They are not suitable for everyone so please ensure you > fully understand the risks involved. The information in this email is not > directed at residents of the United States of America or any other > jurisdiction where trading in CFDs and/or FX is restricted or prohibited > by local laws or regulations.
> The information in this email and any attachment is confidential and is > intended only for the named recipient(s). The email may not be disclosed > or used by any person other than the addressee, nor may it be copied in > any way. If you are not the intended recipient please notify the sender > immediately and delete any copies of this message. Any unauthorised > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden.
> LMAX operates a multilateral trading facility. Authorised and regulated > by the Financial Services Authority (firm registration number 509778) and > is registered in England and Wales (number 06505809). > Our registered address is Yellow Building, 1A Nicholas Road, London, W11 > 4AN.
To answer your first question, no, "ensure=>absent" in a Mount resource will not remove the mount point directory. That is why I've wrapped the File and Mount point in a define, so you can use one definition of nfs_mount to control both mount point and NFS mount together, as in your scenario they are two closely related resources.
You will notice the $state parameter of my defined type is used in two places: for the 'ensure' parameter of the Mount (described in the docs for the Mount type) and the 'ensure' parameter of the File. Since the ensure parameter of the Mount type takes different arguments to the File type, I use a selector to transform the Mount point's state into a state I can use in a File resource. The selector (ensure => $state ? {...} ) basically says this:
"If $state is unmounted, the File is absent"
"If $state is absent, the File is absent"
"If $state is anything else, the File is directory"
As for the second question about the iteration, the iteration works the same way for a defined type as it does for any core Puppet type (File, Mount, Service, etc). Although it's not really a procedural "loop", it's just a short hand way of writing out a set of resource definitions with exactly the same parameters, but the effect is the same.
> # Arrays to iterate over, which would be a little longer than this
> $proddirs = [ "201201", "201202", "201203" ]
> $testdirs = [ "201201", "201202", "201203" ]
> $devdirs = [ "201201", "201202", "201203" ]
> $nfsopts = "tcp,hard,intr,rw,bg"
> By "iterate" I meant to work through a specific array, such as above.
> Reading through the Mount part of the docs, I don't believe that > "absent" will remove the actual directory point, it says:
> "Set it to |absent| to unmount (if necessary) and remove the > filesystem from the fstab"
> So I would handle that by running another iteration over an array for > each section that would have a routine to make sure it's "absent" and > then also rmdir the entry in the filesystem.
> I'm not understanding where the below is iterating or over where... as > $name would need to be defined somehow.
> Thanks!
> On Tuesday, September 25, 2012 5:09:15 AM UTC-4, Luke Bigum wrote:
> Hi Forrie,
> With regards to your iteration question, you would need to use a
> defined
> type, something like this (untested):
> nfs_mount { $production: server => $server, prefix => $prefix}
> See the documentation for the Mount type in Puppet and it's ensure
> parameter for possible values for $state in the define above - it's
> possible to have entries in /etc/fstab but not actually mounted,
> which
> should satisfy your two stage cleanup, or you can just set $state to
> 'absent' straight away and clean up the both NFS mount and mount
> point.
> This means you need to maintain two arrays: one of active mount
> points
> and one of decomissioned mounts, however you probably don't need
> to keep
> the decomissioned mounts around for ever, once every server has
> cleaned
> themselves up they can be removed from the manifest.
> On 24/09/12 23:43, Forrie wrote:
> > I have many systems that require NFS mounts for production. Rather
> > than have one entry of file{} and mount{} per NFS import, in a *.pp
> > file, I'd rather set up and iterate over an array. Looking at the
> > docs, I'm not quite sure how to do this properly. We have three
> > groups for which I would need this (production, development, test)
> > that each have their own NFS mounts.
> > Then issue a command to iterate and manage those NFS mounts.
> > Since these change from time-to-time, and require some pruning... I
> > will be left with "unmanaged" resources (ie: directory mount
> points)
> > scattered around that I will need to clean up. I read through some
> > tickets for feature requests and got lost in where this is going --
> > however, to keep the place neat and clean, I'd like to unmanage the
> > mount points and the fstab entries after. The idea of manually
> doing
> > this from system to system isn't good.
> > I'm still new-ish to puppet, so any pointers would be appreciated.
> Information Systems
> Ph: +44 (0) 20 3192 2520
> luke....@lmax.com <javascript:> | http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
> FX and CFDs are leveraged products that can result in losses
> exceeding
> your deposit. They are not suitable for everyone so please ensure
> you
> fully understand the risks involved. The information in this
> email is not
> directed at residents of the United States of America or any other
> jurisdiction where trading in CFDs and/or FX is restricted or
> prohibited
> by local laws or regulations.
> The information in this email and any attachment is confidential
> and is
> intended only for the named recipient(s). The email may not be
> disclosed
> or used by any person other than the addressee, nor may it be
> copied in
> any way. If you are not the intended recipient please notify the
> sender
> immediately and delete any copies of this message. Any unauthorised
> copying, disclosure or distribution of the material in this e-mail is
> strictly forbidden.
> LMAX operates a multilateral trading facility. Authorised and
> regulated
> by the Financial Services Authority (firm registration number
> 509778) and
> is registered in England and Wales (number 06505809).
> Our registered address is Yellow Building, 1A Nicholas Road,
> London, W11
> 4AN.
> -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group.
> To view this discussion on the web visit
Good to see you are almost there! As you've discovered the "looping" in Puppet isn't *really* looping, it's just a shorthand way of creating multiple resources. However, by combining that with a Defined Type, you can effectively reference the same array element multiple times using $name in the define - as we do with the File and Mount resources - and you achieve an approximation of a loop.
Also remember there was a bug in my original post, the File resource needs "default => directory" to create a directory, not "present", as that would create a file instead, but it looks like you've figured that out anyway.
Unfortunately there is no way to recursively create directories in Puppet. You will need to manage the File[/dce/prod/] directory outside of the nfs_mount resources. Why? If you have more than one Prod nfs_mount, you will get duplicate definitions when you try create /dce/prod/ inside the nfs_mount define.
In your example below you have a class called prod-nfs-mounts. Inside this class you could have a file { "/dce/prod": ensure => directory } resource to ensure the parent directory is created.
One mor bug: the Mount resource should have a dependency on the File resource - you can't mount before the mount point is there. Add a parameter 'require => File[$mount_point]' to the mount resource in the define.
Also just so you know, older versions of Puppet don't like dashes (-) in class and variable names, so I would recommend you use underscores where possible.
> I did some tinkering around and came up with something that partially > works. The one problem I ran into was this:
> Sep 26 16:53:55 test-fms puppet-agent[11974]: > (/Stage[main]/Prod-nfs-mounts/Prod-nfs-mounts::Nfs_mount[201202]/File[/dce/ prod/201202]/ensure) > change from absent to present failed: Could not set 'present on > ensure: No such file or directory - /dce/prod/201202 at > /etc/puppet/manifests/classes/prod-nfs-mounts.pp:19
> I changed the default for the "ensure" value to be "directory" and > that didn't help, but this is strange:
> Sep 26 16:56:50 test-fms puppet-agent[12776]: > (/Stage[main]/Prod-nfs-mounts/Prod-nfs-mounts::Nfs_mount[201202]/File[/dce/ prod/201202]/ensure) > change from absent to directory failed: Cannot create > /dce/prod/201202; parent directory /dce/prod does not exist
> Sep 26 16:56:51 test-fms puppet-agent[12776]: Finished catalog run in > 6.08 seconds
> I can't recall, but there is a way to ensure the directory mount point > is recursively present before a mount is attempted.
> It should not be trying to create a local directory, but mounting from > the remote host. I think I'm almost there, but here's the test > class I have thus far:
> # If the state is "unmounted" the mount point > 'File' needs to be removed somehow, after
> file { $mount_point:
> ensure => $state ? {
> "unmounted" => absent,
> "absent" => absent,
> default => present,
> }
> }
Information Systems
Ph: +44 (0) 20 3192 2520
luke.bi...@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN
FX and CFDs are leveraged products that can result in losses exceeding
your deposit. They are not suitable for everyone so please ensure you
fully understand the risks involved. The information in this email is not
directed at residents of the United States of America or any other
jurisdiction where trading in CFDs and/or FX is restricted or prohibited
by local laws or regulations.
The information in this email and any attachment is confidential and is
intended only for the named recipient(s). The email may not be disclosed
or used by any person other than the addressee, nor may it be copied in
any way. If you are not the intended recipient please notify the sender
immediately and delete any copies of this message. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is
strictly forbidden.
LMAX operates a multilateral trading facility. Authorised and regulated by the Financial Services Authority (firm registration number 509778) and
is registered in England and Wales (number 06505809). Our registered address is Yellow Building, 1A Nicholas Road, London, W11
4AN.
