Chiming in...

The old feature request at https://projects.puppetlabs.com/issues/4815 
<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.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d0331f9a-30e0-423a-babe-9cb4c28c70fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to