Puppet users - Jul 2012 - NFS mounts with puppet creates error

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.

(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.

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.

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.

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.