On Wednesday, 21 June 2017 19:17:09 UTC+1, Rob Nelson wrote:
>
> Have you tried to create the link manually to see what happens?
>
By design, the directory containing the link is owned by root,
because we don't want anybody but root to be able create the link.
And root can use
ln -s - /var/opt/installation-swindon/JobRequests
/etc/JobRequests/swindon
to create one of the two links that Puppet is struggling with.
Except that the link it creates is owned by root, and I'm asking puppet to
create
links owned by (in this case) "swindon".
So I did some tests:
If I run puppet with the root-owned "swindon" link in place,
puppet changes the ownership to "swindon".
If I change the manifest to not specify ownership of the link,
it creates a "swindon" link link owned by root.
If I restore the original manifest and remove the "swindon" link,
puppet still/again fails with the permissions message
BUT
If I remove one of the links puppet previously created ("dorset")
puppet puts it back, owned by "dorset".
So puppet can create links and leave them owned by root.
And it can make existing links owned by some (any?) other user.
But it can't do both at the same time for "swindon".
Even though it can for "dorset".
Which looks to me like a puppet bug...
>
> 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.
>
Well, an upgrade MIGHT fix it....
But I guess that upgrading is something I'm going to have to think about
some time...
Unlikely, but wanted to make sure you're aware.
>
>
> On Wed, Jun 21, 2017 at 1:13 PM Robert Inder <rob...@interactive.co.uk
> <javascript:>> 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...@googlegroups.com <javascript:>.
>> 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/fa808cc2-eb3e-45a1-828d-d044969f2224%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
