Jira (PUP-7057) User provider shows plaintext password when it changes a managed users password
Title: Message Title James Sweeny commented on PUP-7057 Re: User provider shows plaintext password when it changes a managed users password Moses Mendoza Yep, that definitely looks right. When I got the password to display on Windows it was Puppet 4.2. 4.8 behaves as expected. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-7057) User provider shows plaintext password when it changes a managed users password
Title: Message Title James Sweeny commented on PUP-7057 Re: User provider shows plaintext password when it changes a managed users password Using Sensitive() would probably solve this issue for this one customer's case, however I think this ticket should clarify that this is a Windows specific issue. The default behavior for the User type on Linux systems (with only a string for the password parameter) is to redact the change. E.g.,: Notice: /Stage[main]/Main/User[testuser]/password: changed password Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-6932) Gem Provider Windows Ruby Path
Title: Message Title James Sweeny updated an issue Puppet / PUP-6932 Gem Provider Windows Ruby Path CS Priority: Normal CS Frequency: 2 CS Severity: 3 CS Business Value: 2 Change By: James Sweeny CS Priority: Needs Priority Reviewed Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1510) Facts from symlinked folders (facts.d / modules) don't work correctly in Vagrant on Windows
Title: Message Title James Sweeny updated an issue Facter / FACT-1510 Facts from symlinked folders (facts.d / modules) don't work correctly in Vagrant on Windows CS Priority: Normal CS Frequency: 1 CS Severity: 3 CS Business Value: 2 Change By: James Sweeny CS Priority: Needs Priority Reviewed Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1413) External facts do not override custom Ruby facts that have confines or a non-default weight
Title: Message Title James Sweeny created an issue Facter / FACT-1413 External facts do not override custom Ruby facts that have confines or a non-default weight Issue Type: Bug Assignee: Unassigned Created: 2016/05/10 1:50 PM Priority: Normal Reporter: James Sweeny In Facter 2.x, external facts (txt, yaml, json, etc.) would override the value set by custom Ruby facts and core facts. In Facter 3, this is the case only when the Ruby fact being overridden has no confines and a default weight. When a custom Ruby fact in Facter 3 sets one or more confines, it will override all external facts. Desired behavior is that external facts override Ruby facts. When a custom fact without confines should be overwritten by an external fact: [root@server ~]# facter -p testfact RIGHT [root@server~]# cat /opt/puppetlabs/puppet/cache/lib/facter/test.rb
Jira (FACT-1413) External facts do not override custom Ruby facts that have confines or a non-default weight
Title: Message Title James Sweeny updated an issue Facter / FACT-1413 External facts do not override custom Ruby facts that have confines or a non-default weight Change By: James Sweeny Affects Version/s: FACT 3.1.6 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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 https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-4047) consider 'non productive expression' to be warning
Title: Message Title James Sweeny commented on PUP-4047 Re: consider 'non productive _expression_' to be warning In cases like that, would it make more sense to warn that there's a space between the variable and the array operator? If you Google "non-productive (construct|_expression_)" the only results are puppet-related, so it's not a very user-friendly warning. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- 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.
Jira (PUP-4047) consider 'non productive expression' to be warning
Title: Message Title James Sweeny commented on PUP-4047 Re: consider 'non productive _expression_' to be warning Thanks for opening this Henrik Lindberg. In my opinion, we shouldn't even warn in cases like the example above, since there's absolutely nothing functionally wrong with the code from a user's perspective. If it's a style concern, I would rather this be in a linter than squawking during every compile (similar to having variables within single quotes). That said, there are probably other examples you can think of where this kind of warning/error would actually prevent something unexpected from happening, so it might just be something we have to get more specific about. Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- 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.
Jira (PUP-927) puppet apply on Windows always uses *nix style newlines from templates
Title: Message Title James Sweeny commented on PUP-927 Re: puppet apply on Windows always uses *nix style newlines from templates Eric Sorenson can you help me understand why this is being dropped for 4.x (or even a 3.x release)? This is a really painful bug when you're working from a Windows workstation. Add Comment This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e) -- 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.
Jira (PUP-3069) Use a manifest setting in [master] as global manifests
Title: Message Title James Sweeny commented on an issue Re: Use a manifest setting in [master] as global manifests That makes sense, thanks. It was the relative paths that were confusing me. I think this is probably good. Add Comment Puppet / PUP-3069 Use a manifest setting in [master] as global manifests In some puppet installations, especially when an ENC is in use, there are not really any environment specific manifests. Instead the ENC controls all of the classes that are included for a node. However, there is still some global setup that needs to take place outside of the ENC. One example of this is globally setting up a filebucket for all file resour... 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.
Jira (PUP-3069) Use a manifest setting in [master] as global manifests
Title: Message Title James Sweeny commented on an issue Re: Use a manifest setting in [master] as global manifests default_manifest : describes where to find a directory environment's manifest(s); may be either absolute or relative. If relative, it is relative to a given directory environment root. There's an awful lot to try to follow here. Joshua Partlow, can you please give an example configuration that allows a global site.pp in this latest proposal? Add Comment Puppet / PUP-3069 Use a manifest setting in [master] as global manifests In some puppet installations, especially when an ENC is in use, there are not really any environment specific manifests. Instead the ENC controls all of the classes that are included for a node. However, there is still some global setup that needs to take place outside of the ENC. One example of this is globally setting up a filebucket for all file resour... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google
Jira (PUP-3069) Use a manifest setting in [master] as global manifests
Title: Message Title James Sweeny commented on an issue Re: Use a manifest setting in [master] as global manifests What's the current work around for this case? Is it just to set puppet.conf 'manifest' to something static '/our/absolute/manifests/site.pp' and the individual environments have an agreed upon classname convention for a class that always gets picked up from an environment (as I think you described in your first post?) Yep, the current workaround (and I can think of customers who do this) is to not let environments have a site.pp at all, and basically do: modulepath=.../environments/$environment/modules manifest = $confdir/manifests/site.pp In my experience, sites doing this do not classify from site.pp, and use an ENC. If they weren't using an ENC though, I'd think the workaround would be include $::role in the global site.pp or something with hiera_include. Add Comment Puppet / PUP-3069 Use a manifest setting in [master] as global manifests In some puppet installations, especially when an ENC is in use, there are not really any environment specific manifests. Instead the ENC controls all of the classes that are included for a node. However, there is still some global setup that needs to take place outside of the ENC. One example of this is globally setting up a filebucket for all file res
Jira (PUP-3069) Use a manifest setting in [master] as global manifests
Title: Message Title James Sweeny commented on an issue Re: Use a manifest setting in [master] as global manifests via the manifest setting with an interpolated $environment, aka dynamic environments and then there was a third way: 3) The manifest setting in an [envname] puppet.conf section if $environment == 'envname', which is what we've been calling legacy environments. Maybe this case never comes up for professional PE deployments? But I didn't want to leave it out in case it has other issues. Yes, agreed there is a third way. I didn't mention it because it is basically a subset of dynamic environments, and its functionality is mostly easily recreated in directory environments now. > In both cases, "site.pp" was a configurable name. > > PE users of (2) needed to replicate default resources into each environment, and though I don't know > of any complaints, the way PE included filebucket was a common "gotcha". James Sweeny can you clarify for me here; are you saying that PE users who began using dynamic environments had to account for PE expecting to have certain resources commonly loaded via $confdir/manifests/site.pp? And if so, what was/is the work around there? Correct, specifically the default filebucket, and the filebucket configured as a File resource default in site.pp. The workaround for the original case, and in directory environments, is to instruct users that those items need to be included if they deviate from the default manifest. > Users of (1) are able to have a global site.pp that lacks environment-based promotion, but can be > set by a group separate from the ones releasing control repositories. I argue that we need to > preserve the old capabilities, and clearly document PE-specific "gotchas" to close this. What I understand about this issue from you and Eric Sorenson is that this is an authorization issue. Some customers expect that they can have two different authorized roles; one which has authority over puppet.conf and which can declare a global manifest and enc, and another role or roles which can make per environment module changes? And the problem with directory environments for these customers, is that it allows the environment role to control the manifest? Yep. > I propose: > > 1) Bring back the "manifest" option in puppet.conf, with the same behavior it has pre-3.6. This > would be applied as the default manifest in all environments, regardless of any configurations in > respective environment.conf files. Throw warnings if an environment.conf tries to override, or if > puppet.conf's "manifest" contains "$environment." But what you're asking for here is both to bring back the old setting and give it new semantics as an uber manifest setting at the same time. Both for documenation confusion and just the implementation difficulty, I don't think we should do this. But is there a different setting we need to add...or, first, am I right that what you are looking for here is an 'overridding_manifest' which would take precedence over any environment specific one?
Jira (PUP-3069) Use a manifest setting in [master] as global manifests
Title: Message Title James Sweeny commented on an issue Re: Use a manifest setting in [master] as global manifests So, prior to directory environments, there are two ways site.pp can be specified: 1) $confdir/manifests/site.pp 2) $confdir/environments/$environment/site.pp In both cases, "site.pp" was a configurable name. PE users of (2) needed to replicate default resources into each environment, and though I don't know of any complaints, the way PE included filebucket was a common "gotcha". Users of (1) are able to have a global site.pp that lacks environment-based promotion, but can be set by a group separate from the ones releasing control repositories. I argue that we need to preserve the old capabilities, and clearly document PE-specific "gotchas" to close this. I propose: 1) Bring back the "manifest" option in puppet.conf, with the same behavior it has pre-3.6. This would be applied as the default manifest in all environments, regardless of any configurations in respective environment.conf files. Throw warnings if an environment.conf tries to override, or if puppet.conf's "manifest" contains "$environment." 2) Add a "default_manifest" option in puppet.conf which acts as a fallback if neither puppet.conf nor environment.conf specify "manifest." Warn or error if puppet.conf specifies both. For both items proposed above, a precedence configurable in puppet.conf would be nice, but not mandatory. For item (1) proposed above, we should provide documented recommendations for companies that wish to allow the environment to specify a default manifest of its own. I would imagine this to involve creating a module in the environment that acts as a replacement "site.pp" with the owner of puppet.conf's site.pp including class with an internally agreed on name (e.g., "include acme_base"). This is just my opinion. The only thing I would fight strongly for is that users not lose any capabilities that existed prior to directory environments. Add Comment Puppet / PUP-3069 Use a manifest setting in [master] a
Jira (PUP-2938) Directory environments should support a global modulepath
Title: Message Title James Sweeny commented on an issue Re: Directory environments should support a global modulepath No complaints here. Add Comment Puppet / PUP-2938 Directory environments should support a global modulepath Directory environments introduces three new configuration options to replace modulepath: "basemodulepath" and "environmentpath" in puppet.conf and "modulepath" in separate environment.conf files (one for each environment). If a modulepath is specified in an environment's environment.conf file, the basemodulepath is not used unless directly referenced else... 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.
Jira (PUP-2938) Directory environments should support a global modulepath
Title: Message Title James Sweeny commented on an issue Re: Directory environments should support a global modulepath Thanks Andy Parker, I updated the description to clarify. The fact is, a global modulepath, is not there as it stands when using modulepath in environment.conf. If you have to/can set the same value in every instance, I would hardly call it global. Yes, you could configure it such that each environment has the same "fallback" or "override" module path, but that needs to be done for each environment if you make any per-environment changes to the modulepath. You have the request right that there should be a global overriding modulepath, that is the same regardless of environment. I would argue that it should not be overridden, but whether it is or not may be a choice a user would want (I don't have a strong opinion on it, others may). My only opinion on over-writing is that doing so should be explicit. That is, the user should know that they are replacing a value that was defined somewhere else for some reason. On precedence, you laid out two options, and there's technically a third: 1) environment modules are searched before global 2) global modules are searched before environment 3) configurable I lean strongly towards 1. Configurable precedence (3) would (I imagine) create a lot more work, and definitely some UX questions (how do we set it? more config parameters? where do we set it? etc.). For global-before-environment precedence, I don't have a strong argument, and I'm having trouble thinking of use cases that would not be effective (and I have not seen anyone do this in the wild, though I'm sure I'll be corrected). For environment before global, at least one obvious use case springs to mind: Puppet Enterprise! Granted, it shouldn't matter either way if all the pe_* modules are properly prefixed, but they aren't (in PE 3.3 only 8/19 are). There have been many times in the past where a PE user needed to override a built in module with their own, essentially "taking it out" of PE's control. I'll stop there on that point, since a conversation about the /opt/puppet/share/puppet/modules directory is probably better left to the PE project. Outside of PE, the main use case that comes to mind is companies where the puppet master is a shared service, but independent groups control their own environments. A central infrastructure team manages a set of core modules that are released at a different cadence than the environments themselves, which might all have completely separate release processes (since they serve completely independent business functions). Not to get into the pros and cons of this approach, and the implications about cooperation between teams in the release process, but it's being used in some very large deployments. It would be nice if a single environment's modulepath was the only module path, since every module would be tied to a single rev (likely that of a Puppetfile's repo), but it's not an option for some companies in practice (I won't name them on a public tracker, but feel free to get me 1:1).
Jira (PUP-2938) Directory environments should support a global modulepath
Title: Message Title James Sweeny updated an issue Puppet / PUP-2938 Directory environments should support a global modulepath Change By: James Sweeny Directory environments introduces three new configuration options to replace modulepath: "basemodulepath" and "environmentpath" in puppet.conf and "modulepath" in separate environment.conf files (one for each environment). If a modulepath is specified in an environment's environment.conf file, neither the basemodulepath nor environmentpath are is not used unless directly referenced elsewhere .In the now deprecated method for specifying multiple environments, users often add additional module paths that are global to all environments. A classic example is the path for Puppet Enterprise modules, which would not change from environment to environment on a single master. In the current directory environments implementation, a global module path that is environment independent cannot be set if the environment.conf file uses the modulepath setting. Avoiding the environment.conf setting is not an option, since doing so removes the ability to rename or set multiple modulepaths for an environment.Some possible fixes off the top of my head:1) Make basemodulepath global.2) Add a globalmodulepath option. This is my personal preference, since the name is more intuitive, and also calls out that basemodulepath likely isn't global. However, there is some room for debate about whether this value comes before or after the environment-specified module path. Other options along this line of thinking could get very wordy :)I'd be happy to brainstorm more. Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You rec
Jira (PUP-2938) Directory environments should support a global modulepath
Title: Message Title James Sweeny created an issue Puppet / PUP-2938 Directory environments should support a global modulepath Issue Type: Improvement Assignee: Unassigned Created: 15/Jul/14 4:18 PM Priority: Normal Reporter: James Sweeny Directory environments introduces three new configuration options to replace modulepath: "basemodulepath" and "environmentpath" in puppet.conf and "modulepath" in separate environment.conf files (one for each environment). If a modulepath is specified in an environment's environment.conf file, neither the basemodulepath nor environmentpath are used. In the now deprecated method for specifying multiple environments, users often add additional module paths that are global to all environments. A classic example is the path for Puppet Enterprise modules, which would not change from environment to environment on a single master. In the current directory environments implementation, a global module path that is environment independent cannot be set if the environment.conf file uses the modulepath setting. Avoiding the environment.conf setting is not an option, since doing so removes the ability to rename or set multiple modulepaths for an environment. Some possible fixes off the top of my head: 1) Make basemodulepath global. 2) Add a globalmodulepath option. This is my personal preference, since the name is more intuitive, and also calls out that basemodulepath likely isn't global. However, there is some room for debate about whether this value comes before or after the environment-specified module path. Other options along this line of thinking could get very wordy I'd be happy to brainstorm more.
Jira (HI-46) Hiera should support alternate environments
Title: Message Title James Sweeny commented on an issue Re: Hiera should support alternate environments This is covered a bit in the original Redmine ticket, but the real importance of having environment specific hiera.yaml files comes down to how you release changes to the hierarchy. It's a very common pattern to use multiple environments (very often tied to a VCS branch) to test changes before they get merged into a mainline/moved to production. With hiera.yaml being the same across all environments, it is impossible to make a hierarchy change in dev or a feature branch before merging or deploying to production servers. This seriously cripples many organizations' ability to test changes to the code base, since hierarchy changes need to be done all at once. The argument for this feature is that hiera.yaml should not be any different in terms of how it can be tested from the hieradata itself (which can reference $environment) or the puppet modules and manifests. The only way to do this testing without allowing multiple environment-specific versions of hiera.yaml is to have a separate master for each application landscape and manually move hiera.yaml changes among them. This is, of course, extremely impractical if you're trying to test short-lived feature branches. Add Comment Hiera / HI-46 Hiera should support alternate environments Currently hiera supports one `hiera.yaml` file hardcoded to be in the same location as `puppet.conf` (which is the `config` puppet directive. Having separate `hiera.yaml`'s per puppet environment would go along with having separate `site.pp`'s, modules, etc. per environment.
Jira (PUP-1348) Support for Microsoft .msu packages
Title: Message Title James Sweeny updated an issue Puppet / PUP-1348 Support for Microsoft .msu packages Change By: James Sweeny Labels: customer redmine wf001 Add Comment 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.
