Jira (PUP-2659) Puppet stops working with error 'Attempted to pop, but already at root of the context stack.'
Title: Message Title
Wojciech Urbański commented on an issue
Re: Puppet stops working with error 'Attempted to pop, but already at root of the context stack.'
I've been using a configuration without environments for a while now. (I know that it's going to stop being supported soon, but I haven't migrated this configuration yet). Some catalog runs pass, but then this error happens.
However, while typing this comment I have changed my configuration a bit, adding to master's config
[master]
...
environmentpath = $confdir/environments
and to agents
[agent]
...
environment=production
And moving manifests and modules to directory environments/production. The problem persists.
Add Comment
Puppet / PUP-2659
Puppet stops working with error 'Attempted to pop, but already at root of the context stack.'
After upgrading puppet to version 3.6.1, the following error occurs: {noformat} Attempted to pop, but already at root of the context stack. {noformat} And afterwards log is flooded with following message: {noformat} no 'environments' in {:root_environment=#Puppet::Node::Environment:0x7fe1930f5a38 @manifest=/, @modulepath=[], @name=:*root*...
Jira (PUP-2635) user purge_ssh_keys not purged
Title: Message Title
Doug Byrne commented on an issue
Re: user purge_ssh_keys not purged
For your test, I get the same results.
Notice: Compiled catalog for keytest.doolli.com in environment production in 0.18 seconds
Notice: /Stage[main]/Main/Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea]/ensure: current_value present, should be absent (noop)
Notice: /Stage[main]/Main/Ssh_authorized_key[doug]/ensure: current_value present, should be absent (noop)
Notice: foo: Would have triggered 'refresh' from 2 events
Notice: Class[Main]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.17 seconds
To perform a second test, I created the following as keytest.pp:
keytest.pp
ssh_authorized_key { 'doug':
ensure = present,
key= 'B3NzaC1yc2EDAQABAAABAQC81jWIxrZpzL+IFE9S4yJNMrANeOJke0CbFmk8pBz4rI8RZ+1JBZdD5aZnO15nLVYZlQq1D8BLHy3F02EhfmQBINHUPA373SUedEUPqByQBOslp11sK/u0Op0X7hhW902hOFRszb9VODJifWnkB2bj4FDED6zQf8cIeTIO15CyYxPPeT/EBZ9G4RJsAItXf2ktwWaO94FGcnNYMUzvpsJCMwI4XY8ArqQBsRSrGnauhBD3e1MuqnLF4ujOqLYBwfZ5gw5VSar5i/oSsGswgwjKxmuO0hfTxDVROoIn24AHSTm38lF34djEWIASELEWxDjnFDamawfU2Dpm2MK90Jk/',
type = 'ssh-rsa',
user = 'ubuntu',
}
user { 'ubuntu':
purge_ssh_keys = true,
home = '/home/ubuntu',
}
Then I ran puppet apply:
ubuntu@keytest:~$ sudo puppet apply keytest.pp --noop
Notice: Compiled catalog for keytest.doolli.com in environment production in 0.20 seconds
Notice: /Stage[main]/Main/Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea]/ensure: current_value present, should be absent (noop)
Notice: ubuntu: Would have triggered 'refresh' from 1 events
Notice: Class[Main]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.12 seconds
ubuntu@keytest:~$ sudo puppet apply keytest.pp
Notice: Compiled catalog for keytest.doolli.com in environment production in 0.20 seconds
Notice: /Stage[main]/Main/Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea]/ensure: removed
Error: /Stage[main]/Main/Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea]: Could not evaluate: Cannot write SSH authorized keys without user
Notice: /Stage[main]/Main/Ssh_authorized_key[doug]: Dependency Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea] has failures: true
Warning: /Stage[main]/Main/Ssh_authorized_key[doug]: Skipping because of failed dependencies
Notice: Finished catalog run in 0.11 seconds
Still not quite there.
Debug output follows:
ubuntu@keytest:~$ sudo puppet apply keytest.pp -d
Info: Loading facts in
Jira (PUP-2635) user purge_ssh_keys not purged
Title: Message Title
Felix Frank commented on an issue
Re: user purge_ssh_keys not purged
Oh. Awesome. That one's actually reproducible with my original test, if one omits the --noop flag. I will actually open a new ticket for that.
Concerning the original issue, that seems to be tied to agent/master interoperation then?
Can you try and limit the node's manifest to the minimal reproducing set of resources on the master side?
Add Comment
Puppet / PUP-2635
user purge_ssh_keys not purged
I'm using Puppet 3.6.0 on Ubuntu 12.04 and I'm trying to purge unmanaged ssh authorized keys. I've added this code to my manifest: {code} user { 'ubuntu': purge_ssh_keys = true, home = '/home/ubuntu', } {code} However, no keys are purged. I do see the following lines in the agent debug output: {noformat} Debug: /Stage[main]/Role...
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
Jira (PUP-2660) purging ssh_authorized_key fails because of missing user value
Title: Message Title Felix Frank created an issue Puppet / PUP-2660 purging ssh_authorized_key fails because of missing user value Issue Type: Bug Affects Versions: 3.6.1 Assignee: Felix Frank Components: Catalog Application, Types and Providers Created: 25/May/14 12:20 PM Fix Versions: 3.6.2 Priority: Normal Reporter: Felix Frank Given the file /tmp/keytest with content ssh-rsa B3NzaC1yc2EDAQABAAABAQCpIyCCUkkW4CancW11RlGGmcHyIFtwsgIMQGAdBe3WCc+W9MtZDFEFi3XdHQnSRpbsUuiKhiUIKQfuTWXueWIPxtG+Ujde7Ch5MYPbRZ9MDzSYz2MU8/Ir/y7vNLZBadAR131Ok35qL12TMI0Hpzu2o9Y5ZMaf0uoApZAlotJgSsmFAJyq3rdIeIIpdEvTa3C8Yk9ng1p9Dv3nHdx/SpomFIO7rIKIp/vnxplDMBzU7c3akmbI5G3adcRVbZaxiBgJ4X5OKancyq25jqQtduQmgmDOsyr9+DbhcuUafmHpk/lLQ9c8VgvyqbJBaJ7N45NlBGkaZy/frdSeJ+HSEXTr foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea ssh-rsa
Jira (PUP-2635) user purge_ssh_keys not purged
Title: Message Title
Felix Frank commented on an issue
Re: user purge_ssh_keys not purged
For what it's worth, with the following manifest, the agent exhibited only the problem now solved in PUP-2660.
class purge_problem_pup_2235 {
user { foo: purge_ssh_keys = /tmp/keytest, }
}
include purge_problem_pup_2235
Agent output:
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for geras.localdomain
Info: Applying configuration version '1401051097'
Notice: /Stage[main]/Purge_problem_pup_2235/Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea]/ensure: removed
Error: /Stage[main]/Purge_problem_pup_2235/Ssh_authorized_key[foreman-122dc11d6-bd1e-43e7-a00d-f8e2d0af54ea]: Could not evaluate: Cannot write SSH authorized keys without user
Notice: /Stage[main]/Purge_problem_pup_2235/Ssh_authorized_key[doug]/ensure: removed
Error: /Stage[main]/Purge_problem_pup_2235/Ssh_authorized_key[doug]: Could not evaluate: Cannot write SSH authorized keys without user
Notice: Finished catalog run in 0.25 seconds
Add Comment
Puppet / PUP-2635
user purge_ssh_keys not purged
I'm using Puppet 3.6.0 on Ubuntu 12.04 and I'm trying to purge unmanaged ssh authorized keys. I've added this code to my manifest: {code} user { 'ubuntu': purge_ssh_keys = true, home = '/home/ubuntu', } {code} However, no keys are purged. I do see the following lines in the agent debug output: {noformat} Debug: /Stage[main]/Role...
Jira (FACT-484) virtual fact spews permission errors on Debian unstable
Title: Message Title Felix Frank created an issue Facter / FACT-484 virtual fact spews permission errors on Debian unstable Issue Type: Bug Affects Versions: 2.0.1 Assignee: Felix Frank Components: UX Created: 25/May/14 2:15 PM Environment: Debian sid/jessie, kernel 3.14, Ruby 1.9.3p484 Priority: Minor Reporter: Felix Frank When running facter or facter virtual (or puppet agent/apply fwiw), the following error is emitted (twice) ffrank@geras:~/git/facter$ bundle exec facter virtual Could not retrieve fact='virtual', resolution='anonymous': Permission denied - /sys/firmware/dmi/entries/1-0/raw Could not retrieve fact='virtual', resolution='anonymous': Permission denied - /sys/firmware/dmi/entries/1-0/raw physical Sure enough:
Jira (FACT-484) virtual fact spews permission errors on Debian unstable
Title: Message Title Felix Frank updated an issue Facter / FACT-484 virtual fact spews permission errors on Debian unstable Change By: Felix Frank Environment: Debiansid/jessie,kernel3.14,Ruby1.9.3p484 ,running*without*rootprivileges 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.
Jira (FACT-484) virtual fact spews permission errors on Debian unstable
Title: Message Title
Felix Frank updated an issue
Facter / FACT-484
virtual fact spews permission errors on Debian unstable
Change By:
Felix Frank
Thefollowinghappensonlywhenrunningasanunprivilegeduser. Whenrunning_facter_or_factervirtual_(orpuppetagent/applyfwiw),thefollowingerrorisemitted(twice){noformat}ffrank@geras:~/git/facter$bundleexecfactervirtualCouldnotretrievefact='virtual',resolution='anonymous':Permissiondenied-/sys/firmware/dmi/entries/1-0/rawCouldnotretrievefact='virtual',resolution='anonymous':Permissiondenied-/sys/firmware/dmi/entries/1-0/rawphysical{noformat}Sureenough:{noformat}ffrank@geras:~/git/puppet$ls-l/sys/firmware/dmi/entries/1-0/raw-r1rootroot0May2000:18/sys/firmware/dmi/entries/1-0/raw{noformat}
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.
Jira (PUP-1177) sshkey creates /etc/ssh/ssh_known_hosts with mode 600
Title: Message Title Felix Frank commented on an issue Re: sshkey creates /etc/ssh/ssh_known_hosts with mode 600 Good thinking, but I believe that this goes too far. An existing parsedfile should keep whatever permissions it had before it was rewritten. If we do use replace_file, we commit to one mode that is always enforced. That would make it impossible for users to configure their systems with a non-standard mode for, say, ssh_known_hosts. I feel that it would be much more appropriate to keep using Tempfile, but to go ahead and set its mode to 644 before copying it to the target location. But doing this for all parsedfile providers might be harmful, because some providers might rely on the 0600 default (ssh_authorized_key, I'm looking at you). Add Comment Puppet / PUP-1177 sshkey creates /etc/ssh/ssh_known_hosts with mode 600 Using the sshkey type /etc/ssh/ssh_known_hosts is created with mode 600 by default. This seems undesirable in most situations. I think the default should be 644. I didn't see anything obvious in the sshkey code that set it strictly on purpose. Does puppet default to 600 somewhere? And is there a simple way to tweak a type to use a different mode? Th... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PDB-15) Add config retrieval (and other metrics) to reports
Title: Message Title Kenneth Barber updated an issue PuppetDB / PDB-15 Add config retrieval (and other metrics) to reports Change By: Kenneth Barber Summary: Addconfigretrieval(and perhaps othermetrics)toreports 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.
Jira (PDB-178) Extend reports query parameters and search capabilities
Title: Message Title Kenneth Barber commented on an issue Re: Extend reports query parameters and search capabilities Dominic Cleal see comments on this ticket, this was transferred from redmine, but I believe it was yours. Add Comment PuppetDB / PDB-178 Extend reports query parameters and search capabilities While looking (quickly) at what sort of query operators would be useful to support PuppetDB's report backend instead of Foreman's own ActiveRecord backend, I made a few notes. Hopefully these may help influence the future of the reports query endpoint. * report query filter on received-time * report query filter on environment * report query filter ... 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 (PDB-178) Extend reports query parameters and search capabilities
Title: Message Title Kenneth Barber commented on an issue Re: Extend reports query parameters and search capabilities * report query filter on received-time Almost there, will be released in 2.1 most probably, see PDB-658 which will add all operator support to all fields for all end-points (we're refactoring the query engine to do this make sure this happens always going forward as well). Right now, we are crap at filtering on timestamps, with PDB-658 this will be fixed for reports/events. * report query filter on environment Done now with 2.0. * report query filter on linked event message We'll add subquery support with PDB-658 for this to happen. * report query filter on linked resource name (though Foreman uses the original `Foo[bar]` rather than splitting it) I think we have this, but better with PDB-658. We don't split it though, easy to solve in a client I guess. * storage and output of report metrics (applied, restarted, failed, etc.) Umm, not yet and not planned, We at least store report status with 2.1, but metrics is covered here: PDB-15 * report query filter on individual metrics See above. Once we add metrics, this will happen with the new query engine. * report query filter on whether any metric was non-zero (changes) See above. * subquery support for report query filters (e.g. certname) Coming with PDB-658. * route to retrieve a single report's metadata with a given ID What ID did you want to use? Add Comment PuppetDB / PDB-178 Extend reports query parameters and search capabilities
Jira (PUP-2659) Puppet stops working with error 'Attempted to pop, but already at root of the context stack.'
Title: Message Title
Rob Payne commented on an issue
Re: Puppet stops working with error 'Attempted to pop, but already at root of the context stack.'
Same thing happens, here. Two different puppet masters, both without any environment configured (other than the default 'production' environment).
puppet master --configprint all |grep environment environment = production environment_timeout = 5 environmentpath =
Both masters were running fine (except for too-verbose warnings) on 3.6.0, but are now seeing this issue after updating to 3.6.1.
Add Comment
Puppet / PUP-2659
Puppet stops working with error 'Attempted to pop, but already at root of the context stack.'
After upgrading puppet to version 3.6.1, the following error occurs: {noformat} Attempted to pop, but already at root of the context stack. {noformat} And afterwards log is flooded with following message: {noformat} no 'environments' in {:root_environment=#Puppet::Node::Environment:0x7fe1930f5a38 @manifest=/, @modulepath=[], @name=:*root*...
This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-2661) Invalid parameter allow_virtual for puppet 3.6.1
Title: Message Title
Shaw Xiao created an issue
Puppet / PUP-2661
Invalid parameter allow_virtual for puppet 3.6.1
Issue Type:
Bug
Affects Versions:
3.6.1
Assignee:
Eric Sorenson
Components:
Community
Created:
25/May/14 10:05 PM
Priority:
Normal
Reporter:
Shaw Xiao
I have both master and client puppet machine installed with 3.6.1.
Package {
allow_virtual = true,
}
If I put the above setting as release note (http://docs.puppetlabs.com/puppet/latest/reference/release_notes.html#puppet-361) suggested, I got error Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Invalid parameter allow_virtual on Package[tmpwatch] at /etc/puppet/modules/puppet/manifests/master.pp:9 on node puppet Warning: Not using cache on failed catalog.
