I've ended up doing as John said and creating file resources for all of these directories and links instead of syncing from an existing source.
Works a treat :) Thanks for your help all. Cheers, Tim On Apr 23, 10:58 pm, jcbollinger <[email protected]> wrote: > On Apr 22, 11:41 pm, Tim <[email protected]> wrote: > > > > > > > > > > > Hi All, > > > We are seeing an unfortunate side effect using puppet to manage a > > directory of symlinks pointing to automounted filesystems. It seems > > that as well as verifying that the link matches the desired target > > (readlink/lstat), it is also performing an open() on the links and > > causing the filesystems to be automounted. > > > The pattern here is: > > > file { "/data": > > ensure => directory, > > source => "/nfsmount/links/data", > > recurse => true, > > force => true, > > > } > > > Imagine everything is in the steady state, i.e.: > > > symlink /data/fs1 -> /net/server1/fs1 exists > > symlink /nfsmount/links/data/fs1 -> /net/server1/fs1 exists > > > Then at some point in the run (after doing lstat("/data/fs1"), > > readlink("/data/fs1")), puppet appears to attempt an open("/data/fs1", > > O_RDONLY). > > > IANAE here, but it seems that this open is unnecessary? Once the > > target of the link in the managed directory is verified to match the > > target of the link on the source, that should be sufficient? > > That sounds sensible, but I don't know whether it's practical; some of > Puppet's behaviors are constrained by the underlying Ruby libraries. > In any case, the first thing to try is to set "links => manage" on > your File resource (not "links => ignore", which cannot work when the > desired links are not yet present). > > The bottom line, however, is that recursive File management has always > been a sore spot for Puppet, and it probably always will be. It is > not remotely possible to provide enough information in the parameters > of a single File resource to cover all the possible permutations of > desired behavior. Puppet does a fairly good job of coping with that > when asked to do so, but generally you are better off finding a > different approach. > > If you have a large number of files, then you may be better off > wrapping the whole thing into a custom package (e.g. an RPM), putting > that in a local repository or on a network filesystem, and managing > that package instead of the individual files. If there are only a few > files (that you want to manage) then by all means set up individual > file resources for them. > > John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
