Have you tried to create the link manually to see what happens?

Also you probably know but Puppet 3 is EOL. If the issue is with puppet
itself, rather than perms, it's going to require an upgrade to fix.
Unlikely, but wanted to make sure you're aware.

On Wed, Jun 21, 2017 at 1:13 PM Robert Inder <rob...@interactive.co.uk>
wrote:

> I'm hoping someone can help me diagnose a problem with
> Puppet version 3.8.7 running on CentOS 6.4.
>
> I have a couple of servers with a total of 43 web-accessed software
> systems, each with its own unix user.
>
> These installations are all created from scratch by Puppet, and then
> the appropriate version of the software is installed and configured
> by scripts running as the relevant user.
>
> I have just added a new feature, for running background jobs.
> The feature is enabled for an installation if there is a symlink
> from /etc/JobRequests to a JobRequests directory in that
> installation's home directory.
>
> These symlinks are managed by puppet via a "File" resource:
>
>   file { "${job_requests::service::dir}/${user}" :
>       ensure =>  $status ? {
>         'enabled' => link,
>         default   => absent
>       },
>       owner => $user,
>       target => $queue_dir,
>       require => [ File[ $job_requests::service::dir ] ]
>   }
>
> For 41 of the 43 users/installations, this does what I expected,
> and creates links like these...
>
>    lrwxrwxrwx 1 norfolk       root 35 May 19 16:03 norfolk ->
> /var/opt/installation-norfolk/JobRequests
>
> But for two of the thirty users on one of the servers, I get
>     Error: Could not set 'link' on ensure:
>     Permission denied - /var/opt/installation-swindon/JobRequests or
> /etc/JobRequests/swindon
>     at 60:/etc/puppet/modules/job_requests/manifests/user_files.pp
>
> I've tried a couple of the existing links.
> Puppet puts them back.
>
> But won't create the links for these two installations.
>
> Note that the source directory for the link (/etc/JobRequests) is common.
> And the target directory for all installations is created by the same
> puppet manifests.
> And they all have the same permissions.
>
> "WTF?", as they say.
>
> Any suggestions how to start tracking this down?
>
> Robert.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> 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/9aeb318b-a3be-492d-bc2e-ed7673b32c3e%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/9aeb318b-a3be-492d-bc2e-ed7673b32c3e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Rob Nelson

-- 
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/CAC76iT-7EyDWUk4yhNreoMq0gK70UF-m9YQk3ZApo9bDV0i7Sw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to