Hi Forrie,
My example below uses a defined type
(http://docs.puppetlabs.com/puppet/2.7/reference/lang_defined_types.html) to
group two related resources together, in this case the File resource for
the mount point and the Mount resource for the NFS mount itself.
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"
file { $mount_point:
ensure => $state ? {
"unmounted" => absent,
"absent" => absent,
default => directory,
}
}
I just noticed a bug in my original post, it should be "default =>
directory" to create a directory, not a file :-)
http://docs.puppetlabs.com/puppet/2.7/reference/lang_conditional.html#selectors
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.
So doing these :
file { $proddirs: ... }
mount { $proddirs: ... }
is the same as this:
nfs_mount { $proddirs: ... }
Now the $name parameter or is the namevar of the defined type
(http://docs.puppetlabs.com/puppet/2.7/reference/lang_resources.html#namenamevar).
It's the unique name of the resource, works the same as other Puppet
Types, in the examples below it is the strings "apache" and
"/mnt/server/woof":
package { "apache": }
nfs_mount { "/mnt/server/woof/": }
You can use $name inside a defined type just like any other variable /
parameter.
So in an example use of my defined type, this definition:
nfs_mount{ "201201":
state => "mounted",
server => "nfs-server.domain.com",
prefix => "/our/prefix",
}
Will result in the following standard Puppet resources:
file { "/our/prefix/201201":
ensure => "directory",
}
mount { "/our/prefix/201201":
ensure => "mounted",
device => "nfs-server.domain.com:/our/prefix/201201",
}
Hopefully that explains the use of the defined type in more detail. If
you have any more questions, please ask :-)
-Luke
On 25/09/12 23:09, Forrie wrote:
Thank you for your reply :)
The head of the code would need something like this:
$server = "nfs-server.domain.com"
$prefix = "/our/prefix"
# 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):
define nfs_mount ( $server, $prefix, $state = "mounted" ) {
$mount_point = "${prefix}/${name}"
#If the state is "unmounted" the mount point 'File' is removed
file { $mount_point:
ensure => $state ? {
"unmounted" => absent,
"absent" => absent,
default => directory,
}
}
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.
http://docs.puppetlabs.com/references/latest/type.html#mount
<http://docs.puppetlabs.com/references/latest/type.html#mount>
Hope that helps,
-Luke
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.
>
> here's what I would use:
>
> $server = "server.name.com <http://server.name.com>"
> $prefix = "/some/nfs/root"
>
> # array
> production = [
> "dir1",
> "dir2",
> "dir3",
> "dir4",
> ] # etc etc
>
> 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
<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
<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.
--
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/-/wCGS0RWvZFwJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@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.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
