On Wednesday, August 1, 2018 at 1:13:43 PM UTC-5, Darth Krizz wrote: > > Hey together, > > we added a custom mountpoint on our puppetmaster. On this custom > mountpoint we store some files. > Usually the files are configuration files. > >
I think you mean a Puppet fileserver mount point, since later you seem to suppose that you can refer to the files there via a puppet:/// URL. Some of these comments are written under that assumption. If you actually mean a mount point on which the OS mounts a remote filesystem, then that's a different story. > So now, what is the best way to check following possibilities > <https://www.dict.cc/englisch-deutsch/possibilities.html>? > > If the file exists on the custom mountpoint -> use the file and deploy it > to the target path > <https://www.dict.cc/englisch-deutsch/possibilities.html> > If the file does not exists on the custom mountpoint -> Skip this and go > to next task in the module > <https://www.dict.cc/englisch-deutsch/possibilities.html> > > You can run arbitrary commands on the master and collect the results via Puppet's built-in generate() <https://puppet.com/docs/puppet/5.5/function.html#generate> function. Something like this, for example, might be useful to you: # Obtain an array listing the contents of local directory /my/mount $files = split(generate('/bin/ls', '/my/mount'), '\s+') > Are there any best practices for this? > No, because it's overall a bad idea. > Is it possible with find_file? If yes, how? > Only if your custom mount point is somewhere within one of your modules' files/ directories, and you know the exact name of the file you're looking for. > Or should i use file? > I take it you mean the resource type, not the built-in function. I can think of an ugly, hacky way to use the file function to test for file existence on the master, but I don't recommend it. As for the resource type, if you actually declare a File resource then you're instructing Puppet to manage a file on the target system. There is no combination of parameters that expresses "not really, just kidding." > Can file handle with undef.... Something like this: > > file { '/etc/nfs.conf'. > source => [ > "puppet:///modules/nfs/conf.${host}", > "puppet:///custom_mountpoint/nfs/conf.${host}", > 'undef' > ] > } > > No, undef does not work like that. Even if it were possible to make the source parameter fall back to as if it were not specified in the first place (which is what undef expresses when used as a parameter value), that's wouldn't imply not managing the file at all. As I said, you can obtain a listing of a local directory or otherwise check the existence of local files via the generate function. Having done that, you can use the results to help you decide which File resources to declare. But I don't like that one bit. It breaks modularity, and it puts the decision-making in the wrong place. *Best practices* would be to put any static sources you need into the files/ directory of the module that uses them, and to rely on ordinary external data, via class parameters, to customize which files are actually managed. If your data for a particular node specify that a given file should be managed and the needed file source is not present, then it is right, proper, and desirable that catalog compilation should fail instead of producing an incomplete and therefore possibly inconsistent catalog. 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/be12fa0b-58f8-41f4-8c64-44b05e8d4e32%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
