FAQ
Hi group,

I am managing an NFS mount with puppet. And it does not work, and seriously
I really don't see how this can work out nicely. First I make sure with a
file {} class that the directory I want to mount exists. Cause it is used
by the webserver it should belong to the wwwrun/www group on the system. No
prob.

Then I mount the NFS share on the dir. No prob.

On the 2nd run of puppet though ... Error! The NFS mount point is "changed"
over to root:root with 775 permissions (or 777? I don't remember). Puppet
of course now wants to set the user:group of the dir ... and naturally
fails.

So is there a way to keep this error from happening?


Thanks in advance & greetings,
Axel.

--
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/-/tw1oa58dRhoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Christopher Wood at Jul 31, 2012 at 10:24 pm
    (inline)
    On Tue, Jul 31, 2012 at 05:23:00AM -0700, Axel Bock wrote:
    Hi group,

    I am managing an NFS mount with puppet. And it does not work, and
    seriously I really don't see how this can work out nicely. First I make
    sure with a file {} class that the directory I want to mount exists. Cause
    it is used by the webserver it should belong to the wwwrun/www group on
    the system. No prob.
    This is changing the directory inode on the nfs client.
    Then I mount the NFS share on the dir. No prob.
    Now the inode that your nfs client sees is on the nfs server. It is not the same inode that you just managed with puppet.

    (I say inode, but depending on the nfs server it may not be a unix filesystem behind it.)
    On the 2nd run of puppet though ... Error! The NFS mount point is
    "changed" over to root:root with 775 permissions (or 777? I don't
    remember). Puppet of course now wants to set the user:group of the dir ...
    and naturally fails.
    This is dependent on your nfs server settings. You likely have root_squash set by default (see 'man exportfs'), so any activity as the root user on the nfs client is mapped to a "nobody" or "nfsnobody" (uid 65535 or similar) on the nfs server. Check /etc/exports on the nfs server.
    So is there a way to keep this error from happening?
    You can set no_root_squash on the export and run 'exportfs -a' on the nfs server. Then you might have to remount on the client end.

    The broader issue is whether you should manage file permissions on the nfs client or the nfs server. I haven't decided myself, but if you do it on the server you won't have to reduce security by running no_root_squash. The mount will also arrive with the correct permissions.
    Thanks in advance & greetings,
    Axel.

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    [1]https://groups.google.com/d/msg/puppet-users/-/tw1oa58dRhoJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.

    References

    Visible links
    1. https://groups.google.com/d/msg/puppet-users/-/tw1oa58dRhoJ
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Axel Bock at Aug 1, 2012 at 6:18 am
    Hello Christopher,

    that's a nice explanation. I thought only the contents _under_
    .../nfs-mounted/ would be server-side, not the mount-point itself. Well you
    always learn more. no_root_squash is not an option, I will have a look as
    how to manage that properly on our server side.

    Mainly I just want to have the directory to have the correct permission
    when it is not currently mounted.


    Thanks & greetings,
    Axel.

    Am Mittwoch, 1. August 2012 00:24:21 UTC+2 schrieb Christopher Wood:
    (inline)
    On Tue, Jul 31, 2012 at 05:23:00AM -0700, Axel Bock wrote:
    Hi group,

    I am managing an NFS mount with puppet. And it does not work, and
    seriously I really don't see how this can work out nicely. First I make
    sure with a file {} class that the directory I want to mount exists. Cause
    it is used by the webserver it should belong to the wwwrun/www group on
    the system. No prob.
    This is changing the directory inode on the nfs client.
    Then I mount the NFS share on the dir. No prob.
    Now the inode that your nfs client sees is on the nfs server. It is not
    the same inode that you just managed with puppet.

    (I say inode, but depending on the nfs server it may not be a unix
    filesystem behind it.)
    On the 2nd run of puppet though ... Error! The NFS mount point is
    "changed" over to root:root with 775 permissions (or 777? I don't
    remember). Puppet of course now wants to set the user:group of the dir ...
    and naturally fails.
    This is dependent on your nfs server settings. You likely have root_squash
    set by default (see 'man exportfs'), so any activity as the root user on
    the nfs client is mapped to a "nobody" or "nfsnobody" (uid 65535 or
    similar) on the nfs server. Check /etc/exports on the nfs server.
    So is there a way to keep this error from happening?
    You can set no_root_squash on the export and run 'exportfs -a' on the nfs
    server. Then you might have to remount on the client end.

    The broader issue is whether you should manage file permissions on the nfs
    client or the nfs server. I haven't decided myself, but if you do it on the
    server you won't have to reduce security by running no_root_squash. The
    mount will also arrive with the correct permissions.
    Thanks in advance & greetings,
    Axel.

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To view this discussion on the web visit
    [1]https://groups.google.com/d/msg/puppet-users/-/tw1oa58dRhoJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to
    puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at
    http://groups.google.com/group/puppet-users?hl=en.

    References

    Visible links
    1. https://groups.google.com/d/msg/puppet-users/-/tw1oa58dRhoJ
    --
    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/-/Zv1eyP-mRrQJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Aug 3, 2012 at 2:04 pm

    On Wednesday, August 1, 2012 1:18:51 AM UTC-5, Axel Bock wrote:

    Mainly I just want to have the directory to have the correct permission
    when it is not currently mounted.
    If those permissions are different from the ones that the exported
    directory has on the NFS server, then you have a tricky problem. As
    Christopher described, Puppet cannot directly distinguish between the
    remote directory visible when it is mounted and the mount point directory
    visible when the remote directory is not mounted. This is an intentional
    aspect of the Unix architecture and design.

    Are you sure that you actually need to manage the mount point's
    permissions? They do not matter as long as the remote directory is
    mounted, so perhaps ensuring the remote directory mounted would be
    sufficient.


    John

    --
    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/-/8epspT5wARsJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Axel Bock at Aug 8, 2012 at 5:38 am
    Well, I am creating those directories using puppet, and when nothing's
    mounted I don't want to have to be root to mess around with them. Kind of
    annoying. I went for an exec/unless thing now, in which I simply set the
    permissions on the command line - unless the directory already exists :) .
    Not great, but working.

    Thanks for your answer!


    Am Freitag, 3. August 2012 16:04:48 UTC+2 schrieb jcbollinger:

    On Wednesday, August 1, 2012 1:18:51 AM UTC-5, Axel Bock wrote:


    Mainly I just want to have the directory to have the correct permission
    when it is not currently mounted.
    If those permissions are different from the ones that the exported
    directory has on the NFS server, then you have a tricky problem. As
    Christopher described, Puppet cannot directly distinguish between the
    remote directory visible when it is mounted and the mount point directory
    visible when the remote directory is not mounted. This is an intentional
    aspect of the Unix architecture and design.

    Are you sure that you actually need to manage the mount point's
    permissions? They do not matter as long as the remote directory is
    mounted, so perhaps ensuring the remote directory mounted would be
    sufficient.


    John
    --
    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/-/oF8yxWWvZpYJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 31, '12 at 12:23p
activeAug 8, '12 at 5:38a
posts5
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase