Puppet works on 41 times out of 43. Help?

[Robert Inder]

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.

[Rob Nelson]

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. 

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9aeb318b-a3be-492d-bc2e-ed7673b32c3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson

[Robert Inder]

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...

[jcbollinger]

On Thursday, June 22, 2017 at 5:26:41 AM UTC-5, Robert Inder wrote:

I don't understand why the behavior you describe occurs, but I also don't understand why you are trying to set the owner of the link in the first place, especially if the directory containing it belongs to root.

 

   If I change the manifest to not specify ownership of the link,
             it creates a "swindon" link link owned by root.

So why not go with that?  The link owner is relevant only to modifying or removing the link itself, and since you're managing it via Puppet, I don't see what purpose it serves to relax the permissions for that.  The link owner and permissions have no relevance to traversing the link (see symlink(7)).

John

[Martin Alfke]

> On 22 Jun 2017, at 15:42, jcbollinger <John.Bo...@stJude.org> wrote:
>
>
> So why not go with that? The link owner is relevant only to modifying or removing the link itself, and since you're managing it via Puppet, I don't see what purpose it serves to relax the permissions for that. The link owner and permissions have no relevance to traversing the link (see symlink(7)).

E.g. postgres does not work when the data dir is a link not owned by the postgres user

Martin

[Robert Inder]

On 22 June 2017 at 14:42, jcbollinger <John.Bo...@stjude.org> wrote:

On Thursday, June 22, 2017 at 5:26:41 AM UTC-5, Robert Inder wrote:

I don't understand why the behavior you describe occurs, but I also don't understand why you are trying to set the owner of the link in the first place, especially if the directory containing it belongs to root.

​I was creating a number of files, mostly in the user's own directory,
and I simply I used the same "pattern" for each of them...

 

   If I change the manifest to not specify ownership of the link,
             it creates a "swindon" link link owned by root.

So why not go with that?  

​Now that, thanks to Rob Nelson's ​suggestion (for which many thanks, Rob),

I realise that this will work, that is indeed the route I will go down.

Though there does still seem to be a bug in there somewhere...

 

The link owner is relevant only to modifying or removing the link itself, and since you're managing it via Puppet, I don't see what purpose it serves to relax the permissions for that.  The link owner and permissions have no relevance to traversing the link (see symlink(7)).

John

--

Robert Inder,                                    0131 229 1052 / 07808 492 213
Interactive Information Ltd,   3, Lauriston Gardens, Edinburgh EH3 9HH
Registered in Scotland, Company no. SC 150689
                                           Interactions speak louder than words

[Rob Nelson]

There might be a bug, but again, you're on an EOL version of puppet. It's entirely possible that any issue you're observing has been fixed already.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAKqjJm-vLb-%3D%2BGo4%2BbwNM13JOVipDf0nsoZnk3xmFsUbrs6q6Q%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson