mount point directory permissions

[Paolo Supino]

Hi 

I have the following problem: in a certain module I need to set permissions on a directory after the mount was executed. If I do the following 

file { '/app_dir':

  ensure  => 'directory' 

  owner   => 'app_user' 

  group   => 'app_group' 

  mode   => '2775'

} mount { '/app_dir': 

  ensure => mounted,

  atboot => true, 

  device => /dev/mapper/lv_app, 

  fstype => ext3, 

  options => 'defaults', 

  dump => '1', 

  pass => '2',

  require => File['/app_dir'],

}

This would require 2 rounds of puppet: round 1 to setup directory, mount the filesystem and round 2 to fix permissions set to root:root,0755 by the mount command... 

In looking for a solution I found the following link: https://projects.puppetlabs.com/issues/4815 that asks for the option to add permission settings to mount resource. The request was rejected and in the comments 

 Eric Sorenson writes that it would be trivial to accomplish with a defined type, but without going into details... :-( Can any one give me some details on how to do it with a defined type? 

TIA

Paolo 

[Renan Vicente]

you can use notify for a Exec and use a exec { 'fix permission':

                                                                   command => 'chmod 0755 /app_dir ; chown root:root /app_dir'

                                                                   }

something like that, I didn't test but I guess that you work :D

[Paolo Supino]

Hi Renan 

between the solutions I tried was something like this, only that the exec fix permissions got executed on every run of puppet... 

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/bc2954ad-6c52-4772-8f67-a22d98d81c56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[guto carvalho]

Try to use paramters like unless, refreshonly or onlyinf to trigger the command in specific conditions, not every time, inside your exec.

http://docs.puppetlabs.com/references/latest/type.html#exec-attributes

http://docs.puppetlabs.com/references/latest/type.html#exec-attribute-refreshonly

http://docs.puppetlabs.com/references/latest/type.html#exec-attribute-unless

http://docs.puppetlabs.com/references/latest/type.html#exec-attribute-onlyif

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2BB25BzXeMtPFpbAK3f5MwjfXSGoZJC1%2BfzsQvyVbTZRjVjCbA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
[s]
Guto Carvalho

[Paolo Supino]

Hi Guto 

Too cumbersome: Have to setup a check for ownership, groupship and permissions... :-(

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAHTbNE4ZLzh1Ojy7xsjCFaTXMSyPp-5AYYkwHNC2n4JeRuA5%3DA%40mail.gmail.com.

[Peter Bukowinski]

It may not be the nicest way to handle it, but it's not all that cumbersome. If your mount command is modifying the permissions, than you can tell it to notify an exec resource that fixes the perms.

file { '/app_dir':
  ensure  => 'directory' 
  owner   => 'app_user' 
  group   => 'app_group' 
  mode   => '2775'
} mount { '/app_dir': 
  ensure => mounted,
  atboot => true, 
  device => /dev/mapper/lv_app, 
  fstype => ext3, 
  options => 'defaults', 
  dump => '1', 
  pass => '2',
  require => File['/app_dir'],

  notify => Exec['fix_mount_perms'],
}

exec { 'fix_mount_perms':

  command => 'chmod 2755 /app_dir && chown root:root /app_dir',

  refreshonly => true,

}

Setting the exec's refreshonly parameter to true prevents it from running every time, but it will run any time the mount resource changes.

--

Peter Bukowinski

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2BB25ByT%3D2Rffaswtmpn-A_tUfV_VLSKwC8KD_UbvGvPM1vzng%40mail.gmail.com.

[José Luis Ledesma]

I prefer the exec resource to create the mount point ( with onlyif ! Test-d mountpoint) and the file resource to set the proper permissions.

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/773CA884-651C-4F22-BABE-4C1C2ADDD74F%40gmail.com.

[Stefan Schulte]

On 21.03.2014 19:53, José Luis Ledesma wrote:
> I prefer the exec resource to create the mount point ( with onlyif !
> Test-d mountpoint) and the file resource to set the proper permissions.
>
> Regards,

That's what I'd do, too. But you can use `creates` paramter to do the
check, there is no need to invoke an external command.

exec { 'create_mntpoint_/mnt/foo':
command => '/bin/mkdir -m 0755 /mnt/foo',
creates => '/mnt/foo',
}

-Stefan

[José Luis Ledesma]

A lot cleaner!

Always used creates for unzipping, didn't though about using it for mkdir

Thanks!

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/532EA212.3060008%40taunusstein.net.

[Dirk Heinrichs]

Am 23.03.2014 09:57, schrieb Stefan Schulte:

That's what I'd do, too. But you can use `creates` paramter to do the
check, there is no need to invoke an external command.

    exec { 'create_mntpoint_/mnt/foo':
      command => '/bin/mkdir -m 0755 /mnt/foo',
      creates => '/mnt/foo',
    }

But that's not the OP's problem. Creating the mount point can be perfectly accomplished with a file resource. The problem is to adjust permissions AFTER mounting something there w/o having to wait for the next agent run.

If the permissions of the mount point and the mounted directory are different, that would lead to a permission change ping-pong, unless one leaves the permission and ownership attributes of the mount point file resource untouched and uses an exec with appropriate conditions and "refreshonly=>true", triggered by the mount resource.

HTH...

    Dirk

--

Dirk Heinrichs, Senior Systems Engineer, Engineering Solutions
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Tel: +49 2226 1596666 (Ansage) 1149
Email: d...@recommind.com
Skype: dirk.heinrichs.recommind
www.recommind.com

[Paolo Supino]

Hi Stefan 

you're solution is what I did before I posted to the list, but I feel it's too much of a hack and think that there are cleaner and better ways to do it. 

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/532EA212.3060008%40taunusstein.net.

[Paolo Supino]

Peter 

I like your approach very much and think I'll implemente it :-) 

TIA 

Paolo 

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/773CA884-651C-4F22-BABE-4C1C2ADDD74F%40gmail.com.

[Dirk Heinrichs]

Am 21.03.2014 18:48, schrieb Peter Bukowinski:

exec { 'fix_mount_perms':

  command => 'chmod 2755 /app_dir && chown root:root /app_dir',

  refreshonly => true,

}

Setting the exec's refreshonly parameter to true prevents it from running every time, but it will run any time the mount resource changes.

Shouldn't you add "subscribe=>Mount['/app_dir']", then? Otherwise, there's nothing that triggers the refresh.

Bye...

[Felix Frank]

Hi,

On 03/24/2014 07:53 AM, Dirk Heinrichs wrote:
> But that's not the OP's problem. Creating the mount point can be
> perfectly accomplished with a file resource. The problem is to adjust
> permissions AFTER mounting something there w/o having to wait for the
> next agent run.

the point of using the exec for creating the directory is to have the
file resource *require* the mount, not vice versa.

You really don't get around managing the directory with two resources in
this scenario, one exec and one file.

> If the permissions of the mount point and the mounted directory are
> different, that would lead to a permission change ping-pong, unless one
> leaves the permission and ownership attributes of the mount point file
> resource untouched and uses an exec with appropriate conditions and
> "refreshonly=>true", triggered by the mount resource.

Refreshonly is mostly a Bad Idea. The creates parameters in Stefan's
code makes sure that the command is run exactly once (except the
mountpoint gets deleted, then it will have to run again).

From that point on, the permissions will only ever be managed by the
file resource.

Cheers,
Felix

[Peter Bukowinski]

That's what the notify parameter in the mount resource does.

-- Peter

On Mar 24, 2014, at 5:38 AM, Dirk Heinrichs <d...@recommind.com> wrote:

Am 21.03.2014 18:48, schrieb Peter Bukowinski:

exec { 'fix_mount_perms':

  command => 'chmod 2755 /app_dir && chown root:root /app_dir',

  refreshonly => true,

}

Setting the exec's refreshonly parameter to true prevents it from running every time, but it will run any time the mount resource changes.

Shouldn't you add "subscribe=>Mount['/app_dir']", then? Otherwise, there's nothing that triggers the refresh.

Bye...

    Dirk

--
<Logo.gif>

Dirk Heinrichs, Senior Systems Engineer, Engineering Solutions
Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
Tel: +49 2226 1596666 (Ansage) 1149
Email: d...@recommind.com
Skype: dirk.heinrichs.recommind
www.recommind.com

--

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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/532FFD22.9040502%40recommind.com.

[Dirk Heinrichs]

Am 24.03.2014 12:10, schrieb Peter Bukowinski:

That's what the notify parameter in the mount resource does.

Yes, you're right. I always use subscribe instead of notify and didn't even recognize you use the latter ;)

Bye...

    Dirk

--

[otheus uibk]

Chiming in...

The old feature request at https://projects.puppetlabs.com/issues/4815 had it right. This should be a part of the core Mount resource type. Eric's rejection of it was stupid. On most systems, when you mount a volume, the underlying file or directory must first be there. After you mount, the permissions of the mounted directory may need to be changed for whatever reason. In another thread, it was argued that the underlying filesystem -- if it's NFS -- should have the permissions set on the server; that's a silly argument, but more importantly, the underlying filesystem might be a newly created one at the time of deployment. So either before or after, a File resource is needed. Actually, both, but because we can't define the same resource twice, we have to choose one. And because the alternative currently seems to be an Exec resource, the solution is system dependent. (Or, we have to go through a lot of trouble).

The following is an ugly hack, and must be tweaked for each system. This example works for linux:

 mount { 'fs:/mountpoint':

   name=> '/mountpoint',

   device=> 'fs:/vol/devid',

   ensure=> mounted,

   require=> Exec[mount-ensure-mountpoint],

   ...

 }

 file { '/mountpoint':

   # After mountpoint has been created

   owner=> newownerid,

   group=> newgroupid,

   mode=> '0770'

   require=> 'Mount[fs:/mountpoint]',
}

exec { 'mount-ensure-mountpoint'

   command=> 'mkdir -p m 0755 /mountpoint',

   creates=> '/mountpoint'

}

I suppose a refreshonly => true in the Exec resource might provide a tiny optimization.
Creating a custom type or function to do the above is silly, given that nearly every systemadmin needs. 

I cannot currently figure out PUppetlabs' new issue tracking/search system, otherwise I would try to add this to a ticket there.

[Garrett Honeycutt]

Hi,

You can use ghoneycutt/types, which has a class for mount[1]. It ensures
the directory exists for the mount by using `mkdir -p`.

You can use it directly from Hiera as per the docs or through a manifest
like this.


types::mount { '/srv/nfs/home':
ensure => 'present',
device => 'nfsserver:/export/home',
fstype => 'nfs',
options => 'rw,rsize=8192,wsize=8192',
}

[1] - https://github.com/ghoneycutt/puppet-module-types#mount

Best regards,
-g

--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658

[jcbollinger]

Eric does give details.  In a followup comment, he refers to this example, which apparently relies on the puppetlabs/mount_providers Forge module.  Except the example seems to miss the point: as far as I can tell, it does nothing to address setting permissions of either the mount point directory or of the root of the filesystem mounted on it.  It furthermore relies on the defined() function, which I cannot endorse under any circumstances.  I think you need to regard his comment as a non sequitur.

We have discussed the matter here before, and I don't think the request is trivial at all.  In fact, there is no general solution with acceptable characteristics.

To see that, you need to recognize that Puppet is expected to manage the state of the system on an ongoing basis, not merely to set it up in a one-time provisioning sense.  Consider, then, what happens if there is already a filesystem mounted on the mount point. Puppet cannot even check, much less change, the properties of the mount point directory without first unmounting the filesystem from it, and unless the filesystem is to be ensured unmounted, it is simply unacceptable for Puppet to unmount the filesystem to manage the underlying mount point.

Another way to look at it is that the mount point directory and the mounted filesystem root do not have distinct identities.  That's more or less a design feature of a UNIX-style single-root filesystem.  You can tell which one the shared identity refers to at any given time, but you cannot reference them independently.

That does not necessarily mean that you cannot persuade Puppet to do what you want, but you should at least consider whether this should be a job for pre-Puppet provisioning.  If you insist on doing it with Puppet, then the details of what you want factor in to how you would implement it.  In general, however, the shared identity problem means that you cannot manage both mount point and mounted root via File resources.  Unless you want to write a custom resource type, that leaves you with using an Exec for one or the other to (maybe) accomplish everything in one catalog run.


John