Jira (PUP-6615) purge_ssh_keys parameter is not idempotent
Title: Message Title
Jonathan Lynch updated an issue
Puppet / PUP-6615
purge_ssh_keys parameter is not idempotent
Change By:
Jonathan Lynch
If you try to create a user using puppet and set purge_ssh_keys option to true, it fails unless the user already exists. For example:{ quote} { user { 'foobar':ensure => present,managehome => true,purge_ssh_keys => true, } {quote } } Expected result:The user and home directory gets created if it doesn't already exist. If it does already exist, any non-managed authorized_keys get purged.Actual result:{color:red}Error: Failed to apply catalog: Parameter purge_ssh_keys failed on User[foobar]: Munging failed for value true in class purge_ssh_keys: purge_ssh_keys can only be true for users with a defined home directory {color}
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-6615) purge_ssh_keys parameter is not idempotent
Title: Message Title
Jonathan Lynch updated an issue
Puppet / PUP-6615
purge_ssh_keys parameter is not idempotent
Change By:
Jonathan Lynch
If you try to create a user using puppet and set purge_ssh_keys option to true, it fails unless the user already exists. For example:{ { noformat} user { 'foobar':ensure => present,managehome => true,purge_ssh_keys => true, } {noformat } } Expected result:The user and home directory gets created if it doesn't already exist. If it does already exist, any non-managed authorized_keys get purged.Actual result:{color:red}Error: Failed to apply catalog: Parameter purge_ssh_keys failed on User[foobar]: Munging failed for value true in class purge_ssh_keys: purge_ssh_keys can only be true for users with a defined home directory {color}
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-6615) purge_ssh_keys parameter is not idempotent
Title: Message Title
Jonathan Lynch created an issue
Puppet / PUP-6615
purge_ssh_keys parameter is not idempotent
Issue Type:
Bug
Affects Versions:
PUP 3.8.7
Assignee:
Unassigned
Created:
2016/08/15 1:00 PM
Priority:
Minor
Reporter:
Jonathan Lynch
If you try to create a user using puppet and set purge_ssh_keys option to true, it fails unless the user already exists. For example:
user
Unknown macro: { 'foobar'}
Expected result:
The user and home directory gets created if it doesn't already exist. If it does already exist, any non-managed authorized_keys get purged.
Actual result:
Error: Failed to apply catalog: Parameter purge_ssh_keys failed on User[foobar]: Munging failed for value true in class purge_ssh_keys: purge_ssh_keys can only be true for users with a defined home directory
Jira (PUP-4039) package resource doesn't find new packages in yum repo
Title: Message Title Jonathan Lynch commented on PUP-4039 Re: package resource doesn't find new packages in yum repo Interesting, so it seems like if we find a better way to detect a virtual package then this issue will be resolved. 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-723) Due to prefetching, Yumrepo clobbers any definition that it does not create
Title: Message Title Jonathan Lynch updated an issue Puppet / PUP-723 Due to prefetching, Yumrepo clobbers any definition that it does not create Change By: Jonathan Lynch Comment: I'm not sure why [https://projects.puppetlabs.com/issues/1843] is marked as a duplicate of this, but augeas doesn't fix that issue. I'm writing this here because it was marked as a duplicate, but if you all think I should put it in a separate issue I will.Puppet seems to cache/prefetch the repository details at the beginning of the puppet run, meaning that I can't install a repository using yumrepo and install a package from that same repository during the same puppet run. The first puppet run, it adds the repository but seems to be working off its prefetched data so the package install fails. The second puppet run updates the yum cache so now the package install succeeds.https://groups.google.com/forum/#!topic/puppet-users/MossJ_4ngQ8I've found a few threads that suggest using a "yum clean metadata" exec to work around this problem, but shouldn't yumrepo just do this on its own?EDIT: After more searching it looks like https://tickets.puppetlabs.com/browse/PUP-4039 more directly addresses my issue... 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,
Jira (PUP-4039) package resource doesn't find new packages in yum repo
Title: Message Title Jonathan Lynch commented on PUP-4039 Re: package resource doesn't find new packages in yum repo Thank you for responding, because you helped me realize my error. The actual problem was that the repository wasn't getting installed before the package. Once I ensured the repository was installed first the problem went away. 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-4039) package resource doesn't find new packages in yum repo
Title: Message Title Jonathan Lynch commented on PUP-4039 Re: package resource doesn't find new packages in yum repo Adding an exec to refresh the metadata is a valid workaround, but I really think puppet should handle that on it's own. Otherwise the documentation for the yumrepo type should be updated to say "if you want this to work properly you'll need to add an exec to your manifest". 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-723) Due to prefetching, Yumrepo clobbers any definition that it does not create
Title: Message Title Jonathan Lynch commented on PUP-723 Re: Due to prefetching, Yumrepo clobbers any definition that it does not create I'm not sure why 1843(https://projects.puppetlabs.com/issues/1843) is marked as a duplicate of this, but augeas certainly doesn't fix that issue. I'm writing this here because it was marked as a duplicate, but if you all think I should put it in a separate issue I will. Puppet seems to cache/prefetch the repository details at the beginning of the puppet run, meaning that I can't install a repository using yumrepo and install a package from that same repository during the same puppet run. The first puppet run, it adds the repository but seems to be working off its prefetched data so the package install fails. The second puppet run updates the yum cache so now the package install succeeds. Even using the requires or before directives this problem still happens, so it seems to be related to some sort of prefetching that puppet is doing. Whether that's a part of puppet itself or part of the yumrepo type I do not know. So this is counterintuitive and not idempotent and all that. Maybe the yumrepo type could refresh the cache after it installs a repository? 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-2908) service provider should default to upstart in RHEL6 and greater
Title: Message Title
Jonathan Lynch commented on an issue
Re: service provider should default to upstart in RHEL6 and greater
The default is the real issue, because otherwise in a diverse environment I have to basically recreate puppet's logic, e.g.
if $osfamily == 'redhat' { if $operatingsystemmajrelease = 5 { $serviceprovider = 'redhat' }
else { $serviceprovider = 'upstart' }
} if $osfamily == 'ubuntu' { etc... }
service { 'vmware-tools': enable = true, ensure = running, provider = $serviceprovider, }
I can't just take the default because RHEL6 breaks, but if I'm going to make it a variable I have to recreate the entire logic. I suppose I could work around this by
service { 'vmware-tools': enable = true, ensure = running, }
if $osfamily == 'redhat' and $operatingsystemmajrelease == 6 { service { 'vmware-tools': enable = true, ensure = running, provider = upstart, }
}
Add Comment
Puppet / PUP-2908
service provider should default to upstart in RHEL6 and greater
In RHEL6, init was replaced with upstart. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html In puppet, when osfamily = redhat,suse, the provider for the service type defaults to the redhat type, which uses chkconfig. http://docs.puppetlabs.com/references/latest/type.html#service-provider...
Jira (PUP-2908) service provider should default to upstart in RHEL6 and greater
Title: Message Title Jonathan Lynch created an issue Puppet / PUP-2908 service provider should default to upstart in RHEL6 and greater Issue Type: Bug Affects Versions: 3.4.2 Assignee: Kylo Ginsberg Components: Types and Providers Created: 08/Jul/14 12:24 PM Environment: Red Hat Enterprise Linux Priority: Minor Reporter: Jonathan Lynch In RHEL6, init was replaced with upstart. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html In puppet, when osfamily = redhat,suse, the provider for the service type defaults to the redhat type, which uses chkconfig. http://docs.puppetlabs.com/references/latest/type.html#service-provider-redhat However, chkconfig is not available in RHEL6 by default, because it uses upstart now. Actually, maybe this is a chkconfig bug, because chkconfig doesn't work for enabling upstart services, it gives an error...
