I''ve read a couple of bug reports via Google about problems managing directories recursively with Puppet. Another article suggests to create a resource that points to an empty directory on the file store, then use file resources to populate it (which I cannot get to work). The common error being: Error 400 on SERVER: Not authorized to call search on /file_metadata/ usr/local/my/empty-dir with {:checksum_type=>"md5", :recurse=>true, :links=>"manage"} When I look at the configuration directives, and I see the usage of "recurse => true" I assume the directory structure will be created. Why does this not work? Some assumptions could be made on the proper ownership of the unmanaged /sub/directory/tree/dir (upper directories). What''s the best way to work with this issue? Thanks. -- 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.
First of all it isn''t a great idea to use recursive if there are a lot of files/directories. Puppet does a pretty bad job on that, and it will eat your CPU. It is better to launch external program such as: rsync to perform this function. However if you only have few directories or files this is fine. It sounds like you have a permission problem. On Thu, Mar 31, 2011 at 2:06 PM, Forrie <forrie@gmail.com> wrote:> I''ve read a couple of bug reports via Google about problems managing > directories recursively with Puppet. Another article suggests to > create a resource that points to an empty directory on the file store, > then use file resources to populate it (which I cannot get to work). > > The common error being: > > Error 400 on SERVER: Not authorized to call search on /file_metadata/ > usr/local/my/empty-dir with > {:checksum_type=>"md5", :recurse=>true, :links=>"manage"} > > When I look at the configuration directives, and I see the usage of > "recurse => true" I assume the directory structure will be created. > Why does this not work? Some assumptions could be made on the proper > ownership of the unmanaged /sub/directory/tree/dir (upper > directories). > > What''s the best way to work with this issue? > > > Thanks. > > -- > 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. > >-- 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.
I only have a directory like: /usr/local/nagios/libexec for which I want to manage the plugins on the clients. It''s pretty simple. So are you suggesting the better approach may be to exec a mkdir -p as a requirement in the head of the *.pp as a dependency? Meaning, it would detect if the directory structure is already there and if not, mkdir -p. -- 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.
Arnau Bria
2011-Mar-31 20:30 UTC
Re: [Puppet Users] Re: Managing directories, recursively?
On Thu, 31 Mar 2011 13:19:21 -0700 (PDT) Forrie Forrie wrote:> I only have a directory like: > > /usr/local/nagios/libexec > > for which I want to manage the plugins on the clients. It''s pretty > simple. > > So are you suggesting the better approach may be to exec a mkdir -p as > a requirement in the head of the *.pp as a dependency? Meaning, it > would detect if the directory structure is already there and if not, > mkdir -p.or simply, add more directories as depency... file { ''/usr/local/nagios'': ; ''/usr/local/nagios/libexec'': requires => File[''/usr/local/nagios''], owner => ''nagios'', mode => 755; } HTH, Arnau -- 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.
That doesn''t work - I still get the same type of errors, with something like this: file { "/usr/local/nagios": ; "/usr/local/nagios/libexec": requires => File[''/usr/local/nagios''], owner => ''root'', mode => 655, group => ''root'', ensure => directory, } It says that require is an invalid parameter. Here is the full output of the log errors: Mar 31 16:43:02 my-server puppet-agent[28997]: Starting Puppet client version 2.6.4 Mar 31 16:43:03 my-server puppet-agent[28997]: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter requires at /etc/puppet/manifests/classes/nagios-test.pp:26 on node my- server Mar 31 16:43:03 my-server puppet-agent[28997]: Using cached catalog Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- test/File[/usr/local/nagios/libexec]) Failed to generate additional resources using ''eval_generate'': Error 400 on SERVER: Not authorized to call search on /file_metadata/usr/local/nagios/libexec-empty with {:checksum_type=>"md5", :recurse=>true, :links=>"manage"} Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- test/File[/usr/local/nagios/libexec]) Could not evaluate: Error 400 on SERVER: Not authorized to call find on /file_metadata/usr/local/nagios/ libexec-empty Could not retrieve file metadata for puppet:///usr/local/nagios/libexec-empty: Error 400 on SERVER: Not authorized to call find on /file_metadata/usr/local/nagios/libexec- empty at /etc/puppet/manifests/classes/nagios-test.pp:17 Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- test/File[/usr/local/nagios/libexec/check_nfs_mounts.sh]) Dependency File[/usr/local/nagios/libexec] has failures: true Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- test/File[/usr/local/nagios/libexec/check_nfs_mounts.sh]) Skipping because of failed dependencies Mar 31 16:43:04 my-server puppet-agent[28997]: Finished catalog run in 0.30 seconds On Mar 31, 4:30 pm, Arnau Bria <arnaub...@pic.es> wrote:> On Thu, 31 Mar 2011 13:19:21 -0700 (PDT) > > Forrie Forrie wrote: > > I only have a directory like: > > > /usr/local/nagios/libexec > > > for which I want to manage the plugins on the clients. It''s pretty > > simple. > > > So are you suggesting the better approach may be to exec a mkdir -p as > > a requirement in the head of the *.pp as a dependency? Meaning, it > > would detect if the directory structure is already there and if not, > > mkdir -p. > > or simply, add more directories as depency... > > file { > ''/usr/local/nagios'': ; > ''/usr/local/nagios/libexec'': > requires => File[''/usr/local/nagios''], > owner => ''nagios'', > mode => 755; > > } > > HTH, > Arnau-- 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.
On Mar 31, 3:46 pm, Forrie <for...@gmail.com> wrote:> That doesn''t work - I still get the same type of errors, with > something like this: > > file { "/usr/local/nagios": ; > "/usr/local/nagios/libexec": > requires => File[''/usr/local/nagios''], > owner => ''root'', > mode => 655, > group => ''root'', > ensure => directory, > } > > It says that require is an invalid parameter.Puppet is right (but you have quoted its message incorrectly). The metaparameter is spelled "require", not "requires", and use of the latter spelling will cause Puppet justifiably to complain about an invalid parameter.> Here is the full output of the log errors: > > Mar 31 16:43:02 my-server puppet-agent[28997]: Starting Puppet client > version 2.6.4 > Mar 31 16:43:03 my-server puppet-agent[28997]: Could not retrieve > catalog from remote server: Error 400 on SERVER: Invalid parameter > requires at /etc/puppet/manifests/classes/nagios-test.pp:26 on node my- > server > > Mar 31 16:43:03 my-server puppet-agent[28997]: Using cached catalogNote that that is warning you that whatever changes you made to your manifests, Puppet is not using them. Instead, it is using the most recent catalog it successfully retrieved (c.f. "cached").> Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- > test/File[/usr/local/nagios/libexec]) Failed to generate additional > resources using ''eval_generate'': Error 400 on SERVER: Not authorized > to call search on /file_metadata/usr/local/nagios/libexec-empty with > {:checksum_type=>"md5", :recurse=>true, :links=>"manage"} > Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- > test/File[/usr/local/nagios/libexec]) Could not evaluate: Error 400 on > SERVER: Not authorized to call find on /file_metadata/usr/local/nagios/ > libexec-empty Could not retrieve file metadata for > puppet:///usr/local/nagios/libexec-empty: Error 400 on SERVER: Not > authorized to call find on /file_metadata/usr/local/nagios/libexec- > empty at /etc/puppet/manifests/classes/nagios-test.pp:17 > Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- > test/File[/usr/local/nagios/libexec/check_nfs_mounts.sh]) Dependency > File[/usr/local/nagios/libexec] has failures: true > Mar 31 16:43:04 my-server puppet-agent[28997]: (/Stage[main]/Nagios- > test/File[/usr/local/nagios/libexec/check_nfs_mounts.sh]) Skipping > because of failed dependencies > Mar 31 16:43:04 my-server puppet-agent[28997]: Finished catalog run in > 0.30 secondsAs Marek already wrote, it looks like you have a permissions problem. Whatever user the puppetmaster is running as must have read permission on all the files you want it to serve, and must have both read and execute permissions on all the directories in your recursive tree and all the ancestor directories of its root. If you have additional access controls active (e.g. SELinux) then those must also permit the puppetmaster user to read all the files and traverse the directory tree. John -- 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.
I found that the file struct under /etc/puppet/files was owned by root (oops, fixed). However, in using this method outlined earlier, I''m still not able to get the desired result:> file { "/usr/local/nagios": ; > "/usr/local/nagios/libexec": > requires => File[''/usr/local/nagios''], > owner => ''root'', > mode => 655, > group => ''root'', > ensure => directory, > }Mar 31 17:11:06 test-fms puppet-agent[29221]: (/Stage[main]/Nagios- test/File[/usr/local/nagios/libexec]/ensure) change from absent to directory failed: Cannot create /usr/local/nagios/libexec; parent directory /usr/local/nagios does not exist I find this very confusing - perhaps it''s simpler to ''exec'' a ''mkdir - p'' in here as a dependency if the structure doesn''t exist? -- 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.
This actually seems to work better: file { "/usr/local/nagios": ensure => directory, owner => ''root'', group => ''root'', mode => 655, } file { "/usr/local/nagios/libexec": require => File[''/usr/local/nagios''], ensure => directory, owner => ''root'', group => ''root'', mode => 655, } It''s more verbose, but it works. I would still like to see something in puppet that does some recursive directory creation/management. Thank you to those who responded. -- 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.
Felix Frank
2011-Apr-01 13:22 UTC
Re: [Puppet Users] Re: Managing directories, recursively?
On 03/31/2011 11:13 PM, Forrie wrote:> I found that the file struct under /etc/puppet/files was owned by root > (oops, fixed). > > However, > > in using this method outlined earlier, I''m still not able to get the > desired result:That''s because this still isn''t right.> >> file { "/usr/local/nagios": ;This resource is missing an ensure, which should be "directory".>> "/usr/local/nagios/libexec": >> requires => File[''/usr/local/nagios''], >> owner => ''root'', >> mode => 655, >> group => ''root'', >> ensure => directory, >> }The hint about an explicit require was a bad one. Puppet will add this require on its own. You want to do this: file { [ "/usr/local/nagios", "/usr/local/nagios/libexec"]: ensure => directory, mode => 644, # 655 is nonsense. group => "root"; } 655 is nonsense because puppet changes 644 (and 655) to 755 (when you specify +r, you get +x for free). Cheers, Felix -- 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.
On Mar 31, 4:45 pm, Forrie <for...@gmail.com> wrote:> This actually seems to work better: > > file { "/usr/local/nagios": > ensure => directory, > owner => ''root'', > group => ''root'', > mode => 655, > } > > file { "/usr/local/nagios/libexec": > require => File[''/usr/local/nagios''], > ensure => directory, > owner => ''root'', > group => ''root'', > mode => 655, > } > > It''s more verbose, but it works. I would still like to see something > in puppet that does some recursive directory creation/management.Puppet has it in the top-down form governed by the File type''s "recurse" parameter, rather than in a bottom-up form analogous to "mkdir -p". I think that''s consistent: if you don''t tell Puppet what properties the ancestor directories it may need to make should have, then Puppet can neither be sure to get it right nor verify on subsequent runs. To tell Puppet what the properties should be, you must write resource declarations for the ancestor directories. In addition, the reason your other version did not work appears at least partly to be that you did not specify a value for the "ensure" property (or any other) for File "/usr/local/nagios". The <title><colon> <semicolon> declares a resource with an empty property list (following the colon and terminated by the semicolon). My apologies that I did not notice before. The resource reference does not fully document what a File means in that case, but it would be surprising if it meant that a directory of the specified name should be present. My guess would be that it''s a no-op. This may be what you were originally looking for: file { [ "/usr/local/nagios", "/usr/local/nagios/libexec" ]: owner => ''root'', mode => 655, group => ''root'', ensure => directory, } You could also use an array-valued variable to specify the names instead of an array literal. That declares both of the listed directories, assigning the same property values to them. These are general features of Puppet resource declarations, in no way specific to the File type. Note also that for cases like this one, an explicit "require" parameter is not needed; Puppet can and does automatically figure out and use file dependencies such as the one between those two directories. John -- 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.
Arnau Bria
2011-Apr-01 14:17 UTC
Re: [Puppet Users] Re: Managing directories, recursively?
On Fri, 01 Apr 2011 15:22:03 +0200 Felix Frank wrote: Hi, just checking puppet mail list now. as the author of the "great" example I want to say that my main purpose was to say that instead of mkdir, you can declare as many dirs as you want and then, create some kind of relationship between them. The values where senseless and the syntax was not checked (require/s). Apart from that, didn''t know about file { [ "/usr/local/nagios", "/usr/local/nagios/libexec" ]: which automagically creates file dependency. so I declared it in two diff files. sorry for confusing you Forrie, and thanks to the others for you extended explanation. Next reply will be more extended/accurate , I promise. Cheers, Arnau -- 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.
On Apr 1, 9:17 am, Arnau Bria <arnaub...@pic.es> wrote:> Apart from that, didn''t know about > file { [ "/usr/local/nagios", "/usr/local/nagios/libexec" ]: > > which automagically creates file dependency. so I declared it in two > diff files.Clarification: that syntax introduces one property list that applies to all the files named in the array. It is not special with respect to file dependencies, however. Puppet will automagically create dependencies between declared files wherever one is the parent directory of the other, regardless of where each is declared or the syntax of the declarations. John -- 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.