On Tuesday, October 15, 2013 3:21:42 PM UTC-5, Forrie wrote: > > Thanks for the reference, John. > > We need to ensure that these remote mounts are owned/grouped by specific > UID/GID -- hence why I had ownership involved there. We could do this via > UID/GID only (not name) if that works better? I don't understand how > apply that ownership to /home/201301 would affect / or /home. > >
Managing /home/201301 etc. does not itself affect /home, but the definition you presented attempted to manage /home separately along with each of its managed subdirectories. That's what caused your duplicate declaration problem when you attempted to declare multiple instances of that defined type. It's actually a pretty common breakage pattern -- when you define a type that must support multiple instances, it must declare only resources that are different for each defined type instance, but people seem to want to include declarations of common resources on which all the instances rely. Those common resources need to be factored out so that they are declared only once globally, instead of once for each defined type instance. If you want to manage the uid/gid/permissions of the mounted remote filesystem, then you should manage them on the host that exports them, not on the client machines. The remote uid/gid/permissions are the ones that will be presented on client machines. On the other hand, you do not need to be concerned with the properties of the underlying mount point directory because *they are invisible and do not matter at all when the remote file system is mounted*. > Then, Puppet would need to check that it's present, has the correct > permissions and owership, and ensure it's mounted -- or, in the case of > aged data, not mounted and not present. > > In the event that you want the remote mount to be present, you need to account for two basic cases: 1. The remote file system is initially unmounted (regardless of the presence or properties of its target mount point directory), and 2. The remote file system is initially mounted (and therefore its mount point directory is present). Because the mount point directory must be present in order for anything to be mounted on it, you must instruct Puppet to manage the corresponding File resource before it manages the Mount resource. But when you apply that File (e.g. File['/home/201301']) in case (1) you are managing the mount point directory, whereas when you apply it in case (2) you are managing the remote file system root. You cannot do both in one run with one resource. Moreover, the uid/gid/permissions do not matter in case (1) because, I repeat, *they are invisible and do not matter at all when the remote file system is mounted*. At the same time, NFS clients cannot modify uid/gid/permissions in case (2) if the NFS server performs root squashing, which it should. Thus, the File resources for the mount point directories should manage only their presence as directories, not uid/gid/permission. That will work in both cases, doesn't do any unnecessary work in case (1), and doesn't attempt anything that cannot reliably be done in case (2). The uid/gid/permissions need to be managed on the exporting host. The other direction, where you want the mount absent, is easier at least. You just ensure the Mount absent and ensure the File absent, but you must be certain to do it in that order (the reverse of the order needed when you want the mount present). 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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
