Using file and mount more efficiently

[Forrie]

I have several NFS mounts to manage, on many systems.  On each system, I must ensure that the root directory and path exist and have the correct permissions beforehand, then ensure they are mounted in Puppet.

For each, I would normally do:

        file { "/home/directory1":

               ensure => directory,

               owner   => "user",

               group  => "group",

               mode   => "755",

       }

       mount { "/home/directory1":

               device   => "our-thumper.domain.com:/export/directory1",

               atboot   => yes,

               fstype   => "nfs",

               options  => "tcp,hard,intr,rw,bg",

               name     => "/home/directory1",

               ensure   => mounted,

               remounts => true,

               pass     => "0",

               require => File["/home/directory1"], 

       }

 

which isn't very efficient when you have a ton of them to mange.

It doesn't appear that Puppet can iterate through an array, but could I do something like:

file { "/home/directory1", "/home/directory2", "/home/directory3":

but requiring this File will be a problem in the "mount" pass.

Perhaps a template?

How are others solving this sort of problem?   For me, it would be a lot easier (and more readable) if we could maintain an array at the top of the rules that contained either the full patch or the basename, then iterate through them.

_F

[maill...@gmail.com]

You can fake interation. "$name" is a free variable for whatever you're passing in. I have NOT tested this, but it might look something like this:

define my_mounts {
   mount { "/home/$name":

               device   => "our-thumper.domain.com:/export/$name",

               atboot   => yes,

               fstype   => "nfs",

               options  => "tcp,hard,intr,rw,bg",

               name     => "/home/$name",

               ensure   => mounted,

               remounts => true,

               pass     => "0",

               require => File["/home/$name"], 

       }

}

Then call it with:

my_mounts { $mounts: }

--
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...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Forrie]

So I would need to define $mounts, presumably as:

$mounts = "directory1 directory2 directory3" 

?

Where is $name being defined here.

[Peter Bukowinski]

You define an array-containing variable like this:

    $mounts = [ 'directory1', 'directory2', 'directory3' ]

You can also put newlines after the commas for easier reading. The following code should be functional:

class test_case {

    $mounts = [

        'directory1',

        'directory2',

        'directory3',

    ]

    define my_mounts {

        file { "/home/${name}":

            ensure => directory,

            owner => "$name",

            mode => "0755",

        }

        mount { "/home/${name}":
            device   => "our-thumper.domain.com:/export/${name}",

            atboot   => yes,
            fstype   => "nfs",
            options  => "tcp,hard,intr,rw,bg",

            name     => "/home/${name}",

            ensure   => mounted,
            remounts => true,
            pass     => "0",

            require => File["/home/${name}"], 

        }

    }

    my_mounts { $mounts: }

}

Of course, instead of defining the $mounts variable in the manifest itself, you can get that array via a custom fact or from hiera.

--

Peter

[maill...@gmail.com]

... and $name is the default variable given to you by puppet, so you don't have to define it.  Works like $_ in perl.

[jcbollinger]

On Wednesday, August 21, 2013 1:39:05 PM UTC-5, Forrie wrote:

I have several NFS mounts to manage, on many systems.  On each system, I must ensure that the root directory and path exist and have the correct permissions beforehand, then ensure they are mounted in Puppet.

 

 

What Nick and Peter jointly described is certainly the approach I would take to a problem of this general nature, but I want to point out that this particular problem has another dimension that may cause you trouble: conflation of the mount point directory and the root of the remote file system.

 

This is not so much a Puppet issue as a Unix one: while a filesystem is mounted on (say) /home/directory1, all references to that path are resolved to the root of the mounted filesystem, whereas when nothing is mounted there the path refers to the mount point directory.  Therefore, unless you do something to ensure your FS unmounted before the File is applied, the File will sometimes manage the local directory, but other times manage the remote one.  That may be tolerable, but it will not work if you want different properties for the mount point than for the root of the filesystem mounted on it.

 

 

John

 

[jcbollinger]

On Sunday, August 25, 2013 1:54:09 AM UTC-5, jcbollinger wrote:

Therefore, unless you do something to ensure your FS unmounted before the File is applied, the File will sometimes manage the local directory, but other times manage the remote one.  That may be tolerable, [...]

 

I should clarify: it probably is NOT tolerable to unmount and remount the FS during every Puppet run, but it might be tolerable to have Puppet manage the remote filesystem root when that is already mounted.

 

 

John

 

[Forrie]

This is something I've been concerned about -- and how to properly approach this.

For example, we can use Puppet to ensure that the directories (mount points) exist and that the entries are present in /etc/fstab -- but I grow very concerned about automating the NFS-mount part of this.

I don't think we'd want to use autofs, as the namespace isn't visible unless you "cd" directly into it.   We nixed this idea with /home, for example.

What would be the safest ideal way to approach this?

Thanks!

[jcbollinger]

On Thursday, September 19, 2013 1:43:07 PM UTC-5, Forrie wrote:

This is something I've been concerned about -- and how to properly approach this.

For example, we can use Puppet to ensure that the directories (mount points) exist and that the entries are present in /etc/fstab -- but I grow very concerned about automating the NFS-mount part of this.

I don't think we'd want to use autofs, as the namespace isn't visible unless you "cd" directly into it.   We nixed this idea with /home, for example.

A nitpick: you don't specifically have to "cd" into an automounted filesystem to get it mounted; any access at all to the mount point itself or any child path will do ('ls', fopen(3), I/O redirection, etc.).  A child path works to get the filesystem mounted even if it doesn't actually correspond to a real file.

In a few places I use symlinks to automounted directories.  The symlinks provide visibility in the expected location, but I get all the goodness of automounting (however much that may or may not be).

 

What would be the safest ideal way to approach this?

It's not clear what exactly you hope to achieve.  Is it different from what declaring a Mount with ensure => 'present' will do (which is to ensure the fs is listed in fstab without managing whether it is mounted)?

You cannot get around the fact that it is impossible to see or touch the mount point directory underneath a mounted filesystem.  Any access to the mount point path refers to the root of the mounted filesystem instead.  That is a matter of fundamental Unix architecture, quite outside Puppet's scope.


John

[Forrie]

If Puppet were to manage /home/something, an NFS mount, and ensure it's mounted... it would automatically look to see if both /home and / were also mounted?   

In most cases, on our older systems, /home is actually just on / -- a full partition that sits on a raid5 layer.   So, at best, Puppet would just get a standard error that / and /home are already present and mounted.

What I'm concerned about is:

- Ensuring the directories are present, with correct permissions and ownership

- Ensuring that the NFS mount is active and available  (possibly send out an error vis syslog if not)

- NOT causing some bizarre cascade of mount issues by Puppet repeatedly attempting to fix something it cannot, in the case of an error that requires manual intervention.

Our environment is growing substantially, to the point where manually editing fstab is becoming a real PITA, and also creates an environment for inconsistencies (and minor typos).   So I really need Puppet to manage those mounts.

I'm not sure I would need automounter for these.   

Thanks!

[Forrie]

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.

class nfs_mounts_prod {

        define nfs_mounts {

                $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",

                }

                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

        } # 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 :-)

Thanks.

[jcbollinger]

On Monday, September 23, 2013 2:58:30 PM UTC-5, Forrie wrote:

If Puppet were to manage /home/something, an NFS mount, and ensure it's mounted... it would automatically look to see if both /home and / were also mounted?

No.  Puppet manages only the resources you tell it to manage.  Indeed, for the most part it manages only the properties you specify of the resources you tell it to manage.  What makes you think differently?

 

  

In most cases, on our older systems, /home is actually just on / -- a full partition that sits on a raid5 layer.   So, at best, Puppet would just get a standard error that / and /home are already present and mounted.

What I'm concerned about is:

- Ensuring the directories are present, with correct permissions and ownership

That's Puppet's bread & butter.

 

- Ensuring that the NFS mount is active and available  (possibly send out an error vis syslog if not)

I'm not sure what you mean.  You want a remote NFS filesystem recorded in /etc/fstab?  No sweat.  You also want it mounted?  No problem.

You want to manage properties of the mount point directory other than its presence, and also ensure the remote filesystem is mounted?  You can't even do that manually unless you are willing to have a service interruption on the remote filesystem.  If that's OK, though, then you can do it with Puppet.

 

- NOT causing some bizarre cascade of mount issues by Puppet repeatedly attempting to fix something it cannot, in the case of an error that requires manual intervention.

Are you talking about Puppet's reports and / or log output, or what?  Puppet only manages what you tell it to manage.  It will not cause or report on a "bizarre cascade of mount issues", but it will certainly tell you about each failure or inability to put an aspect of the target node into the state that you specified it should be in.

 

Our environment is growing substantially, to the point where manually editing fstab is becoming a real PITA, and also creates an environment for inconsistencies (and minor typos).   So I really need Puppet to manage those mounts.

It can.

 

I'm not sure I would need automounter for these.   

You never need the automounter, and if you are declaring all needed filesystems in /etc/fstab then you don't want to automount them, too.  But automounting could provide a useful alternative to your growing problem with managing fstab.  It also provides for automatic unmounting of inactive filesystems, which can be a big advantage in some situations.


John

[jcbollinger]

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

[Forrie]

Thanks for the reference, John.

We need to ensure that these remote mounts are owned/grouped by specific UID/GID -- hence why I had ownership involved there.   We could do this via UID/GID only (not name) if that works better?   I don't understand how apply that ownership to /home/201301 would affect / or /home.

Then, Puppet would need to check that it's present, has the correct permissions and owership, and ensure it's mounted -- or, in the case of aged data, not mounted and not present.

Thanks.

[jcbollinger]

On Tuesday, October 15, 2013 3:21:42 PM UTC-5, Forrie wrote:

Thanks for the reference, John.

We need to ensure that these remote mounts are owned/grouped by specific UID/GID -- hence why I had ownership involved there.   We could do this via UID/GID only (not name) if that works better?   I don't understand how apply that ownership to /home/201301 would affect / or /home.

Managing /home/201301 etc. does not itself affect /home, but the definition you presented attempted to manage /home separately along with each of its managed subdirectories.  That's what caused your duplicate declaration problem when you attempted to declare multiple instances of that defined type.  It's actually a pretty common breakage pattern -- when you define a type that must support multiple instances, it must declare only resources that are different for each defined type instance, but people seem to want to include declarations of common resources on which all the instances rely.  Those common resources need to be factored out so that they are declared only once globally, instead of once for each defined type instance.

If you want to manage the uid/gid/permissions of the mounted remote filesystem, then you should manage them on the host that exports them, not on the client machines.  The remote uid/gid/permissions are the ones that will be presented on client machines.  On the other hand, you do not need to be concerned with the properties of the underlying mount point directory because they are invisible and do not matter at all when the remote file system is mounted.

 

Then, Puppet would need to check that it's present, has the correct permissions and owership, and ensure it's mounted -- or, in the case of aged data, not mounted and not present.

In the event that you want the remote mount to be present, you need to account for two basic cases:

1. The remote file system is initially unmounted (regardless of the presence or properties of its target mount point directory), and
2. The remote file system is initially mounted (and therefore its mount point directory is present).

Because the mount point directory must be present in order for anything to be mounted on it, you must instruct Puppet to manage the corresponding File resource before it manages the Mount resource.  But when you apply that File (e.g. File['/home/201301']) in case (1) you are managing the mount point directory, whereas when you apply it in case (2) you are managing the remote file system root.  You cannot do both in one run with one resource.  Moreover, the uid/gid/permissions do not matter in case (1) because, I repeat, they are invisible and do not matter at all when the remote file system is mounted.  At the same time, NFS clients cannot modify uid/gid/permissions in case (2) if the NFS server performs root squashing, which it should.

Thus, the File resources for the mount point directories should manage only their presence as directories, not uid/gid/permission.  That will work in both cases, doesn't do any unnecessary work in case (1), and doesn't attempt anything that cannot reliably be done in case (2).  The uid/gid/permissions need to be managed on the exporting host.


The other direction, where you want the mount absent, is easier at least.  You just ensure the Mount absent and ensure the File absent, but you must be certain to do it in that order (the reverse of the order needed when you want the mount present).


John