permission denied errors on /var/lib/puppet stuff during puppetd -t

[Justin Lloyd]

I'm suddenly getting the below errors from Rack during puppetd -t (excerpted from the pink HTML output and cleaned for readability):

Could not prepare for execution: Got 10 failure(s) while initializing:
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/yaml;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/rrd;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/reports;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/facts;
change from absent to file failed: Could not set 'file on ensure: Permission denied - /var/log/puppet/masterhttp.log;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/ssl;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/state;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/lib;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/bucket;
change from absent to directory failed: Could not set 'directory on ensure: Permission denied - /var/lib/puppet/server_data

I'm not sure what I may have changed that would cause this now. Thoughts?

--
“We don’t need to increase our goods nearly as much as we need to scale down our wants. Not wanting something is as good as possessing it.” -- Donald Horban

[Peter Berghold]

I saw that when the userid "puppet" did not exist on a system.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

--
Peter L. Berghold
Owner, Shark River Technical Solutions LLC

[Justin Lloyd]

I did verify correctness of the puppet user in /etc/passwd, shadow, group, and gshadow. I'm also seeing it on multiple systems (probably all) so it's likely something in my config, just not sure what it could be so far.

[Justin Lloyd]

Note that I'm testing puppetd -t on the master, just for simplicity, so I gave it a blank node entry, i.e. "node 'puppet-master' { }", to eliminate recent module changes as the culprit.

[jcbollinger]

The agent (i.e. puppetd) needs to run privileged. It sounds like you
are starting it manually, so are you running it as root or via sudo?

Alternatively, if your master is running SELinux in enforcing mode,
then it is possible that starting the agent manually does not confer
the same privileges that running it as a service does. You can test
this by switching to permissive mode.

Or is /var [on a] read-only filesystem? That's a long shot, because
such a situation would probably cause a lot of other problems system-
wide.


John

[Justin Lloyd]

Well I've somehow managed to get it down to just the error on the masterhttp.log file:

Could not prepare for execution: Got 1 failure(s) while initializing: change from absent to file failed: Could not set 'file on ensure: Permission denied - /var/log/puppet/masterhttp.log

There's obviously something wrong with the file permissions but I don't know what.

# cd /var/log/puppet
# ls -al
total 12
drwxr-x---  2 puppet puppet 4096 2012-03-14 17:21 .
drwxr-xr-x 17 root   root   4096 2012-03-16 06:25 ..
-rw-rw----  1 puppet puppet 2977 2012-03-14 17:22 masterhttp.log
#

We also don't have SELinux configured. Only thing installed is libselinux1.

Apache2 runs as www-data but I think it was like that prior to this problem.

/var is not read-only. I did think of that and verified it before my initial post.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Justin Lloyd]

Finally found the answer in this thread: http://groups.google.com/group/puppet-users/browse_thread/thread/5bc799ee96bf74bd?pli=1

On the puppet master server, /etc/puppet/rack/config.ru was owned by root:root instead of puppet:puppet. My puppet class isn't enforcing that, but hmm, that would be a chicken and egg problem, most likely.

[purple grape]

just disable selinux .

[kegstand]

disabling selinux is never the solution

On Sat, Sep 1, 2012 at 7:16 PM, purple grape <purple...@gmail.com> wrote:

just disable selinux .

[Christopher Wood]

Unfortunately, that rather depends on how much money is available to spend on a solution. (Unpleasant, but true.) I'm going to have difficulty persuading my manager that I should stop my tasks for a few weeks to learn and implement selinux on several Linux-based platforms. From his perspective, I will take some paid vacation from revenue-enhancing tasks in order to add a requirement for increased operational expenditure down the road.

From the perspective of somebody who has only dabbled, selinux is a bit like monitoring: there's a wide and deep ocean of domain knowledge behind a single word. I'd like to know more, but I don't have the time without neglecting my currently assigned tasks.

There's nothing about selinux on the puppet forge right now, but Google turns up any number of links. I liked these:

http://allmybase.com/2011/04/26/easily-managing-selinux-policies-with-puppet/
http://serverfault.com/questions/30796/reasons-to-disable-enable-selinux

But my liking something and my appreciating how it helps are not criteria that will help me implement something on production systems.

On Sat, Sep 01, 2012 at 10:33:43PM -0700, kegstand wrote:
> disabling selinux is never the solution
>

> On Sat, Sep 1, 2012 at 7:16 PM, purple grape <[1]purple...@gmail.com>

> wrote:
>
> just disable selinux .
>
> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.

> To post to this group, send email to [2]puppet...@googlegroups.com.

> To unsubscribe from this group, send email to

> [3]puppet-users...@googlegroups.com.

> For more options, visit this group at

> [4]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...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

> References
>
> Visible links
> 1. mailto:purple...@gmail.com
> 2. mailto:puppet...@googlegroups.com
> 3. mailto:puppet-users%2Bunsu...@googlegroups.com
> 4. http://groups.google.com/group/puppet-users?hl=en

[jcbollinger]

On Sunday, September 2, 2012 12:33:49 AM UTC-5, Dan wrote:

disabling selinux is never the solution

On Sat, Sep 1, 2012 at 7:16 PM, purple grape <purple...@gmail.com> wrote:

just disable selinux .

Well, I do prefer to set selinux to non-enforcing mode instead of actually disabling it, but I don't suppose that's what you meant.

As with anything security-related, it's all about risk and cost / benefit.  If you don't have someone competent to do so managing your SELinux policy, then enforcing SELinux policy is likely to cost you a reduction in stability and periodic loss of functionality.  Turning off policy enforcement or disabling SELinux altogether will be better choices for some people, but if that would represent an unacceptable risk for the particular machine in question, then your next best bet is to hire or train an SELinux policy manager.  If you don't know pretty well how to manage SELinux policy, but you must nevertheless enforce it, then you are going to get your SELinux training the hard way, and chances are your site will feel the pain along with you.


John

[Mr Eathernet]

Thank you! For me, it was in /usr/share/puppet/ext/rack/

The following fixed it:
chown puppet:puppet /usr/share/puppet/ext/rack/config.ru

-eathernet