On Friday, March 21, 2014 at 11:41:25 AM UTC-5, Paolo wrote:
>
> 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
> <https://www.google.com/url?q=https%3A%2F%2Fprojects.puppetlabs.com%2Fissues%2F4815&sa=D&sntz=1&usg=AFQjCNGKlGsPhzHg7nBoT9uJzzRerl661w>
>
> 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?
>
>
Eric does give details. In a followup comment, he refers to this example
<https://github.com/ahpook/puppetlabs-mount-providers/commit/31dc733331af32bb586dbd755b978b2bd074d9cf>,
which apparently relies on the puppetlabs/mount_providers
<https://forge.puppet.com/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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/da68330b-0d15-4c58-99b8-79d6e4f67f0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
