On Monday, September 23, 2013 7:15:32 PM UTC-5, Forrie wrote:
>
> I've been playing around with this code and have encountered several
> errors. As noted below, there is going to be an issue with /home;
> however, I thought I could get around that by declaring that /first/, which
> won't work -- as it complains about duplicate declarations of /home.
>
>
As it should. More on that below.
>
> class nfs_mounts_prod {
>
> define nfs_mounts {
>
As a matter of style and good practice, do not lexically nest classes or
definitions inside classes. Put them in separate files.
Also, put all your classes and definitions into modules. Even if you have
a bunch of local one-offs that don't otherwise go together, either put them
in their own modules or create a grab-bag "site" module to house them.
Neither of those is the source of your errors, but structuring your
manifests well may help clarify the issues.
>
> $server = "ourserver.com"
> $options =
> "tcp,rw,hard,intr,vers=3,tcp,rsize=32768,wsize=32768,bg"
>
> # These needed to be defined here, it would not work
> outside of the class definition
> $prod_mounts = [
> '201301',
> '201301pod',
> ]
>
> file { "/home":
> ensure => directory,
> owner => "root",
> group => "root",
> mode => "0755",
> }
>
>
Why are all those variables and File['/home'] declared inside your
definition, when they do not depend in any way on the properties of any
instance of the defined type? They belong directly in the containing
class, instead. Although it's only a little redundant to put the variable
declarations in the definition, putting the File['/home'] there is what
causes your duplicate declaration errors, as you get one declaration of
that resource for every declared instance of the defined type in which it
resides.
> file { "/home/${name}":
> ensure => directory,
> owner => "16326",
> group => "90",
> mode => "0755",
> require => File["/home"],
> } # file
>
> mount { "/home/${name}":
> device => "${server}:/export/prod/${name}",
> atboot => yes,
> fstype => nfs,
> options => "${options}",
> name => "/home/${name}",
> ensure => mounted,
> remounts => true,
> pass => "0",
> require => File["/home/${name}"],
> } # mount
>
>
That's just broken. As I've been saying, it is seriously problematic to
manage a mount point directory, because what the target path means to the
OS depends on whether the filesystem is mounted on it. Moreover, if your
NFS setup is reasonably secure then you will have trouble getting Puppet to
manage anything about the remote filesystem. This is because the NFS
server will perform root squashing with respect to most or all clients, so
that local root on NFS client systems is mapped to a different,
unprivileged user for the NFS server's purposes.
I also think it's a poor plan to mount each user's home directory
separately. Why not just mount <server>:/export/prod on local /home? That
will be a lot easier on you.
> } # nfs_mounts
>
> nfs_mounts { $prod_mounts: }
>
> } # class nfs_mounts_prod
>
>
> Can you tell me what's wrong -- or if this is even going to work :-)
>
>
Here's a better starting point:
modules/prod/manifests/params.pp:
----
class prod::params {
$nfs_server = "ourserver.com"
$nfs_options = "tcp,rw,hard,intr,vers=3,tcp,rsize=32768,wsize=32768,bg"
}
modules/prod/manifests/nfs_mounts.pp:
----
class prod::nfs_mounts {
file { "/home":
ensure => directory,
owner => "root",
group => "root",
mode => "0755",
}
prod::nfs_homedir { [
'201301',
'201301pod',
]:
}
}
modules/prod/manifests/nfs_homedir.pp:
----
define prod::nfs_homedir {
include 'prod::params'
file { "/home/${name}":
ensure => 'directory'
# Do not manage owner or permissions because this is a
# mount point / remote directory.
#
# We can rely on autorequires to make Puppet manage
# the parent directory first (if it is under management, which
# it is.
}
mount { "/home/${name}":
device => "${prod::params::nfs_server}:/export/prod/${name}",
atboot => yes,
fstype => nfs,
options => "${prod::params::nfs_options}",
ensure => mounted,
remounts => true,
pass => "0",
require => File["/home/${name}"],
} # mount
}
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
