Jira (PUP-3277) Adjust puppet acceptance for puppetserver/classifier installations where environmentpath is set by default.

[Joshua Partlow (JIRA)]

Title: Message Title

Joshua Partlow commented on an issue   Re: Adjust puppet acceptance for puppetserver/classifier installations where environmentpath is set by default. Ok, I think I know what is going on with this dratted woy_cache test. It's interaction between the settings catalog executed by different processes with different uids. The preceding test/loader/func4x_loadable_from_modules.rb executes a puppet apply with a --config option pointing to a temporary puppet.conf without user/group set to pe's service user pe-puppet. The apply's configurer uses the main, ssl and agent settings, causing a settings catalog to be built and run first, and because the apply is running as root and there is no 'puppet' service user, files end up owned as root, including the $ssldir/certs/ca.pem. The next test, node/check_woy_cache_works.rb attempts to restart the puppetserver with a modified version of pe's puppet.conf, and as puppetserver brings up each puppet master instance in its jruby threads, they too attempt to manage the catalog, but, I believe at this point that privilege has been dropped to the pe-puppet service user, who is not allowed to try and chown the $ssldir/certs/ca.pem file owned by root. So the startup process fails and the woy_cache test fails, and you get the log message in the puppetserver.log about permissions. This does not break every following test attempting to start up a puppet master, because the very next puppet agent or puppet apply call will be executed as root by Beaker, and will use pe's puppet.conf, which has a pe-puppet user declared. So it will fix up the permissions on the $ssldir/certs contents again. What made this even trickier to find is that if there is a daemonized puppet agent, as the installer normally provides, this daemonized agent, will itself fix the permissions when $confdir/puppet.conf is touched...so if you are attempting to duplicate the failure on nodes that you have installed pe on, but which haven't had their agent daemons shut off the way the Beaker install_utils does, then the problem is fixed by the daemonized agent noticing the changed puppet.conf and running a settings catalog before the puppetserver brings up it's first puppetmaster thread. And the woy_cache test doesn't fail... I don't think there is anything to ticket here; it's just a peculiar and frustrating interaction of the tests with puppet enterprise. The fix, I believe, is to add the configured puppet service user/group to the --config file used by the func4x_loadable_from_modules.rb test. There may be a few other tests using --config that need similar guards. I will check in the morning. Thanks to Wayne Warren for the auditd suggestion. Add Comment   Puppet / PUP-3277 Adjust puppet acceptance for puppetserver/classifier installations where environmentpath is set by default. A big part of this is preparation for 4.0.x to adjust acceptance setup to use directory environments. This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.