Bug #10968
potential issues with reuse of puppet http method in classify action
| Status: | Needs More Information | Start date: | 11/20/2011 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: |  Dan Bode |
% Done: | 0% |
|
| Category: | cloudpack | Spent time: | - | |
| Target version: | - | |||
| Keywords: | Branch: | |||
| Votes: | 0 |
Description
This is more of a heads up than a known issue with cloudprovisioner, I reused the same http connection code (Puppet::Network::HttpPool.http_instance(options[:enc_server], options[:enc_port]) and found that it was changing the permission of the master’s ssldir when I used the method on the same node as my master.
The main thing that I wanted to point out is that the http call does have side effects that will potentially modify a masters certificates (it took me forever to figure it out :) )
As a temporary workaround, I added the following code before I make the http connection:
Puppet[:ssldir]='/dev/null'
History
Updated by Daniel Pittman 5 months ago
- Category set to cloudpack
- Status changed from Unreviewed to Accepted
- Assignee set to Jeff McCune
- Priority changed from Normal to High
Jeff, this looks like a genuine issue, although I have not chased it all the way through the code to understand the way, just that it seems like that is happening. The proposed work-around might work, but isn’t either portable, or sufficient.
Can you take ownership of this and shepherd it to the right destination to get it fixed?
Updated by Jeff McCune 5 months ago
- Status changed from Accepted to Needs More Information
- Assignee changed from Jeff McCune to Dan Bode
No, sorry. =)
Dan, I’m kicking this back to you. Please confirm this isn’t a configuration mis-match. For example, is the master using one set of permissions for Puppet[:ssldir] and your cloud provisioner process is using a different set of permissions for Puppet[:ssldir]? These different sets of permissions may be because Puppet Master typically runs under a service account while cloud provisioner typically does not.
If the configuration is indeed different, then this isn’t actually a bug in Puppet::Network::HttpPool.http_instance but instead a bug in how it’s being used.
-Jeff
Updated by Dan Bode 5 months ago
Please confirm this isn’t a configuration mis-match. For example, is the master using one set of permissions for Puppet[:ssldir] and your cloud provisioner process is using a different set of permissions for Puppet[:ssldir]? These different sets of permissions may be because Puppet Master typically runs under a service account while cloud provisioner typically does not.
This is a reasonable categorization of the observed behavior. I do not understand why this potentially invalidates the issue.
If the configuration is indeed different, then this isn’t actually a bug in Puppet::Network::HttpPool.http_instance but instead a bug in how it’s being used.
I am not implying this is a bug against Puppet::Network::HttpPool.http_instance (this ticket was not filed against the Puppet project), I am saying that there is a potential issue with how it is used by Cloud Provisioner (which is where this ticket is filed) where using the cloud provisioner on the master may change the ownership of the masters ca directory and break Puppet.
Updated by Jeff McCune 5 months ago
Dan Bode wrote:
Please confirm this isn’t a configuration mis-match. For example, is the master using one set of permissions for Puppet[:ssldir] and your cloud provisioner process is using a different set of permissions for Puppet[:ssldir]? These different sets of permissions may be because Puppet Master typically runs under a service account while cloud provisioner typically does not.
This is a reasonable categorization of the observed behavior. I do not understand why this potentially invalidates the issue.
If the configuration is indeed different, then this isn’t actually a bug in Puppet::Network::HttpPool.http_instance but instead a bug in how it’s being used.
I am not implying this is a bug against Puppet::Network::HttpPool.http_instance (this ticket was not filed against the Puppet project), I am saying that there is a potential issue with how it is used by Cloud Provisioner (which is where this ticket is filed) where using the cloud provisioner on the master may change the ownership of the masters ca directory and break Puppet.
Right, I’m trying to figure out if Cloud Provisioner shouldn’t be using Puppet::Network::HttpPool.http_instance. If it’s simply a matter of the runmode and resulting configuration difference then that indicates Cloud Provisioner is mis-using Puppet::Network::HttpPool.http_instance because the method makes assumptions about the configuration and runmode that aren’t true in Cloud Provisioner.
-Jeff
Updated by Daniel Pittman 3 months ago
Jeff McCune wrote:
Right, I’m trying to figure out if Cloud Provisioner shouldn’t be using Puppet::Network::HttpPool.http_instance. If it’s simply a matter of the runmode and resulting configuration difference then that indicates Cloud Provisioner is mis-using Puppet::Network::HttpPool.http_instance because the method makes assumptions about the configuration and runmode that aren’t true in Cloud Provisioner.
Jeff, did you ever find an answer to this?
Updated by Jeff McCune 3 months ago
Daniel Pittman wrote:
Jeff McCune wrote:
Right, I’m trying to figure out if Cloud Provisioner shouldn’t be using Puppet::Network::HttpPool.http_instance. If it’s simply a matter of the runmode and resulting configuration difference then that indicates Cloud Provisioner is mis-using Puppet::Network::HttpPool.http_instance because the method makes assumptions about the configuration and runmode that aren’t true in Cloud Provisioner.
Jeff, did you ever find an answer to this?
Not that I recall. If it’s not here, which it doesn’t appear to be, then it’s still an outstanding question.
Cloud Provisioner is definitely still using this method, potentially improperly.
lib/puppet/cloudpack.rb 6:require 'puppet/network/http_pool' 547: http = Puppet::Network::HttpPool.http_instance(options[:enc_server], options[:enc_port])