Jira (FACT-1907) facter 3.12.2 choses wrong ip as main ip
Title: Message Title Adam Winberg commented on FACT-1907 Re: facter 3.12.2 choses wrong ip as main ip We just hit this with RHEL9 - we use dhcp as source for our primary ip and then add secondary ip's as static configuration via Puppet. In newer versions of NetworkManager the static configurations have higher priority than dhcp addresses which results in facter using the wrong ip to set for example 'ip', 'netmask' and 'network' facts. https://access.redhat.com/solutions/6961919 To make sure that our dhcp address is used as primary address in routing we therefore have had to set the netmask to '/32' for our secondary addresses. This solves the routing problem (i.e. outgoing traffic uses wrong source ip) but the facter facts are still wrong since the 'ip addr' output puts the statically configured addresses above the primary (dhcp) address. Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.293131.1548279813000.16742.1660742340037%40Atlassian.JIRA.
Jira (PUP-10371) Add metric for Puppet Agent run
Title: Message Title Adam Winberg commented on PUP-10371 Re: Add metric for Puppet Agent run Also, since splaytime is included in the calculation all config reports in Foreman have the same time stamp - HH:01. So it appears that all agents have run at the same time. ( we run puppet agents hourly and trigger the run at HH:01 with a splaylimit of 900s. ) Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.349708.1584344056000.120844.1611229500039%40Atlassian.JIRA.
Jira (PUP-10371) Add metric for Puppet Agent run
Title: Message Title Adam Winberg commented on PUP-10371 Re: Add metric for Puppet Agent run This new `startup_time` metric also includes splaytime which really makes the total run time metric quite useless. Is that a bug or a conscious decision? Add Comment This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.349708.1584344056000.119393.1611156900027%40Atlassian.JIRA.
Jira (PUP-10100) Exec resource should not leak sensitive commands when a relative path is given
Title: Message Title Adam Winberg commented on PUP-10100 Re: Exec resource should not leak sensitive commands when a relative path is given Is it ok for the error message to specify only the executable in the error message? Yes, that would be fine for me. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.329033.1570812974000.1148.1571162880084%40Atlassian.JIRA.
Jira (PUP-6494) exec resources leak the command string when execution fails
Title: Message Title Adam Winberg commented on PUP-6494 Re: exec resources leak the command string when execution fails So this is supposed to be fixed? I get Error: Failed to apply catalog: Validation of Exec[populate_luksfile] failed: 'echo "supersecretpassword"' is not qualified and no path was specified. Please qualify the command or specify a path. with the following code: exec { "echo_passphrase": command => Sensitive("echo \"${secretpw.unwrap}\""), } with puppet-agent-6.10.0-1.el8.x86_64 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-
Jira (PUP-9601) mount resource should trigger 'systemctl daemon-reload'
Title: Message Title Adam Winberg commented on PUP-9601 Re: mount resource should trigger 'systemctl daemon-reload' Regardless of which components you use that is more a question of automount vs. static mounts and I'm not sure why that is relevant here. But some of the advantages for us are: Automounting only mounts on access and automatically unmounts after inactivity so a server only activates a mount if it needs it (less network activity, less hassle if we need to change some mount options). If one mount is having an issue it wont affect system boot (and puppet wont error and time out trying to mount it). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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-9601) mount resource should trigger 'systemctl daemon-reload'
Title: Message Title Adam Winberg commented on PUP-9601 Re: mount resource should trigger 'systemctl daemon-reload' Gheorghe Popescu That doesnt really fit my usecase, since I use systemd for automount. So puppet should only make sure that the mount is added to the fstab but disregard whether the mount is mounted or not (i.e. 'present'). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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-9601) mount resource should trigger 'systemctl daemon-reload'
Title: Message Title Adam Winberg commented on PUP-9601 Re: mount resource should trigger 'systemctl daemon-reload' Additionally you would also need to trigger a systemctl restart remote-fs.target or systemctl restart local-fs.target , depending on whether the mount is remote (for example nfs) or local. Otherwise systemd will not create the mountpoints until next reboot. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because
Jira (PUP-9601) mount resource should trigger 'systemctl daemon-reload'
Title: Message Title Adam Winberg updated an issue Puppet / PUP-9601 mount resource should trigger 'systemctl daemon-reload' Change By: Adam Winberg *Puppet Version: 5.5.3* *Puppet Server Version: 5.3.3* *OS Name/Version: RHEL7*On systemd distributions entries in /etc/fstab automatically generates systemd .mount files, resulting in systemd effectively managing the mount. When changes are made to /etc/fstab, 'systemctl daemon-reload' must be called in order to generate new systemd mount files. It seems natural to me that puppets mount resource automatically should trigger this reload on changes in fstab if systemd is present, which it does not do currently. *Desired Behavior:*Changes in mount resources should always trigger a reload of systemd configuration (systemctl daemon-reload)*Actual Behavior:*Changes in mount resource only updates fstab. Changes will not update corresponding systemd .mount files until reboot or issuing a 'systemctl daemon-reload' manually. This is particularly inconvinient when using systemd automounting.Following puppet mount:{code:java} mount {"/temp": ensure => 'present', device => 'fs_server:/temp', fstype => 'nfs', options => 'noauto,x-systemd.automount,x-systemd.device-timeout=10,x-systemd.mount-timeout=30,x-systemd.idle-timeout=60,_netdev,vers=4.0,sec=krb5 , ' }{code}creates a line in fstab for this mount, but does not create any corresponding systemd mount files. So, in this case, 'mount /temp' will work but not 'systemctl start temp.mount'. On boot, however, systemd will generate mount files (one .mount and one .automount) for this mount automatically. On access the filesystem will be mounted automatically by systemd, and unmounted after 60s of inactivity. If I change mount options for this mount, the fstab will be updated but since the systemd files are not updated any automounting after the change will still use the old options.I can workaround this in my code by notifying a 'systemctl daemon-reload' in my mount definition, but if the mount fails for some reason (typically because of a failed remount) the reload command will not run leaving my system in an inconsistent state. Add Comment
Jira (PUP-9601) mount resource should trigger 'systemctl daemon-reload'
Title: Message Title Adam Winberg created an issue Puppet / PUP-9601 mount resource should trigger 'systemctl daemon-reload' Issue Type: Bug Affects Versions: PUP 5.5.3 Assignee: Unassigned Created: 2019/04/03 4:01 AM Priority: Normal Reporter: Adam Winberg Puppet Version: 5.5.3 Puppet Server Version: 5.3.3 OS Name/Version: RHEL7 On systemd distributions entries in /etc/fstab automatically generates systemd .mount files, resulting in systemd effectively managing the mount. When changes are made to /etc/fstab, 'systemctl daemon-reload' must be called in order to generate new systemd mount files. It seems natural to me that puppets mount resource automatically should trigger this reload on changes in fstab if systemd is present, which it does not do currently. Desired Behavior: Changes in mount resources should always trigger a reload of systemd configuration (systemctl daemon-reload) Actual Behavior: Changes in mount resource only updates fstab. Changes will not update corresponding systemd .mount files until reboot or issuing a 'systemctl daemon-reload' manually. This is particularly inconvinient when using systemd automounting. Following puppet mount: mount {"/temp": ensure => 'present', device => 'fs_server:/temp',
Jira (PUP-9069) Add support for RHEL 8 in systemd provider
Title: Message Title Adam Winberg commented on PUP-9069 Re: Add support for RHEL 8 in systemd provider Could this be merged to the 5.5 release of puppet? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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-5915) exec resources fail unless cwd is readable
Title: Message Title Adam Winberg commented on PUP-5915 Re: exec resources fail unless cwd is readable This is in effect the same as PUP-5808. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- 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-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited Another interesting thing - with 'strict' set to 'error' and trace logging, I actually get three occurences of the error message: 2017-03-09 13:29:39,720 ERROR [qtp182348184-67 - /puppet/v3/catalog/lxserv940.smhi.se?environment=production] [puppetserver] Puppet Class 'settings' is already defined; cannot redefine on node lxserv940.smhi.se 2017-03-09 13:29:39,733 ERROR [qtp182348184-67 - /puppet/v3/catalog/lxserv940.smhi.se?environment=production] [puppetserver] Puppet Class 'settings' is already defined; cannot redefine on node lxserv940.smhi.se 2017-03-09 13:29:39,734 ERROR [qtp182348184-67 - /puppet/v3/catalog/lxserv940.smhi.se?environment=production] [puppetserver] Puppet Server Error: Class 'settings' is already defined; cannot redefine on node lxserv940.smhi.se The first and last of these also outputs stack traces. Is the repetition normal when executing in this manner? Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (PUP-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited if I didnt explicitly mention it before, the errors go away if I set 'environment_timeout' to 0. Also, after restarting the puppetserver (with 'unlimited') the first agent run typically does not trigger this error. But when I run the agent a second time the error appears. 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-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited ok, that actually yielded a trace: 2017-03-09 13:29:39,720 ERROR [qtp182348184-67 - /puppet/v3/catalog/lxserv940.smhi.se?environment=production] [puppetserver] Puppet Class 'settings' is already defined; cannot redefine on node lxserv940.smhi.se /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/errors.rb:106:in `fail' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/type_collection.rb:248:in `dupe_check' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/type_collection.rb:68:in `add_hostclass' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/type_collection.rb:60:in `add' org/jruby/RubyKernel.java:1242:in `catch' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/resource/type_collection.rb:59:in `add' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/parser/compiler.rb:857:in `create_settings_scope' /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/parser/compiler.rb:168:in `compil
Jira (PUP-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited no stack back trace, the log output was the same as with debug logging. 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-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited no luck, there were no TRACE messages in the log output 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-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited yeah sure, I'll be happy to test that. Is the logging level 'trace' also set in the logback configuration? 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-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited debug logging does not reveal much to me, there is no additional mention of the settings class and no obvious clues in connection with the 'already defined' error message. Interesting though is that the error message is showing on some runs, but on others not - with the same client. I've tried to diff the debug logs between two of these runs, but I still cant make out what might be the problem. 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-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited Hm, I have no class named 'settings' and cant really find anywhere in my code where such a class would be defined. Unfortunately the error message does not indicate where in the code things go wrong. The logs have no stacktrace, looks like this: 2017-03-08 17:16:10,240 INFO [qtp1384492760-14005] [puppetserver] Puppet Compiled catalog for lxserv362.smhi.se in environment production in 2.10 seconds 2017-03-08 17:16:11,232 INFO [qtp1384492760-12587] [puppetserver] Puppet Compiled catalog for lxserv666.smhi.se in environment production in 2.11 seconds 2017-03-08 17:16:11,855 WARN [qtp1384492760-12276] [puppetserver] Puppet Class 'settings' is already defined; cannot redefine at : 2017-03-08 17:16:11,950 WARN [qtp1384492760-12389] [puppetserver] Puppet Class 'settings' is already defined; cannot redefine at : 2017-03-08 17:16:13,852 INFO [qtp1384492760-12276] [puppetserver] Puppet Compiled catalog for lxserv683.smhi.se in environment production in 2.00 seconds 2017-03-08 17:16:13,900 INFO [qtp1384492760-12389] [puppetserver] Puppet Compiled catalog for lxserv1296.smhi.se in environment production in 1.95 seconds 2017-03-08 17:16:23,372 WARN [qtp1384492760-12276] [puppetserver] Puppet Class 'settings' is already defined; cannot redefine at :
Jira (PUP-6339) Hiera Data in Module give bad results when environment_timeout is unlimited
Title: Message Title Adam Winberg commented on PUP-6339 Re: Hiera Data in Module give bad results when environment_timeout is unlimited I'm still seeing these warnings ("Puppet Class 'settings' is already defined; cannot redefine at :") in my puppetserver log on v2.7.2. The use case is exactly as described by OP, but I can't see that it actually affects any configuration - that is, everything seems to work as expected. It's mostly an annoyance in my log files, is this expected behaviour? 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-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg commented on PUP-5808 Re: puppet via sudo from nfs home is not working Since our users keep getting hit by this I've done some more digging. The 'problem' lies in the ruby code for the exec resource - puppet/lib/puppet/provider/exec.rb In the 'run' method the method 'checkexe' is called to verify existence of the executable. This code fails if you are running puppet via sudo standing in a directory where root has no permissions - for example an nfs mounted home directory. The reason for this, I'm guessing, is that 'checkexe' uses system calls which inherently tries to operate on the cwd. Setting the 'cwd' parameter for the exec resource in my puppet code has no effect, since the 'chdir' to cwd in puppet/lib/puppet/provider/exec.rb happens after the check_exe call. If I do a Dir.chdir "/tmp" before the 'checkexe' call, everything works as expected. So, to resolve this, which I would consider a bug, I would propose to implement a chdir to a tmp directory on the filesystem before anything else in the run method in puppet/lib/puppet/provider/exec.rb. Any thoughts on this? Add Comment
Jira (PUP-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg commented on PUP-5808 Re: puppet via sudo from nfs home is not working ah, ok - yes, it fails repeatedly, not only for this resource. Sorry for the confusion. It fails since puppet tries to do 'chdir(cwd)' (which is not in my exec resource code) and the current working directory is unavailable for the root user. I should mention that i tried changing the 'cwd' parameter to the exec resource before I discovered that this was not caused by the exec resource in itself and also affected other resources. It should be easily reproduced by running puppet via sudo from a nfs share (make sure no_root_squash is not set). 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-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg commented on PUP-5808 Re: puppet via sudo from nfs home is not working R.I.Pienaar Not sure what you mean. Puppet is not failing on some specific code, it's failing because I run it via sudo from a directory which root does not have permission to (nfs in this case). 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-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg commented on PUP-5808 Re: puppet via sudo from nfs home is not working Any comments on this? Seems like we are the only ones affected by this 'bug'... 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-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg updated an issue Puppet / PUP-5808 puppet via sudo from nfs home is not working Change By: Adam Winberg We use NFS mounted home directories for all our users. If a sysadmin or devop wants to trigger a puppet agent run via sudo, he/she must change dir from the nfs home directory to a local directory, otherwise the puppet run will fail. This is nothing new, but I'd like to know if it is intended behaviour or if it is something that could be fixed. So, running an strace on the puppet agent run, I see that puppet repeatedly executes a 'chdir' to the cwd. These chdirs are typically performed before a stat operation to get the correct path for a provider (i.e. /usr/bin/mount or /usr/local/sbin/mount). When running via sudo from my homedir, this fails since root has no permissions to enter that directory. I can work around this by cd'ing to a local dir before running 'sudo puppet', or invoking sudo with the '-i' flag, but to make it failsafe for our devops it would be better if they didnt have to think about that. I would suggest to use the default tempdir of the system (linux=/tmp) instead of the cwd for these chdir operations . But , but I probably might fail to see the complete picture. Outtake from strace log:{noformat}chdir("/home/a001329") = -1 EACCES (Permission denied)write(2, "\33[1;31mError: /Stage[pre]/Core::"..., 137^[[1;31mError: /Stage[pre]/Core::Users::Update_root_pw/Exec[set_grub2_password]: Could not evaluate: Permission denied - /home/a001329^[[0m) = 137write(2, "\n", 1) = 1sendto(7, "<27>Feb 3 11:48:42 puppet-agent"..., 161, MSG_NOSIGNAL, NULL, 0) = 161write(1, "\33[mNotice: /Stage[pre]/Core::Use"..., 131^[[mNotice: /Stage[pre]/Core::Users::Update_root_pw/Exec[grub2-mkconfig]: Dependency Exec[set_grub2_password] has failures: true^[[0m) = 131write(1, "\n", 1) = 1sendto(7, "<29>Feb 3 11:48:42 puppet-agent"..., 158, MSG_NOSIGNAL, NULL, 0) = 158write(2, "\33[1;31mWarning: /Stage[pre]/Core"..., 121^[[1;31mWarning: /Stage[pre]/Core::Users::Update_root_pw/Exec[grub2-mkconfig]: Skipping because of failed dependencies^[[0m) = 121write(2, "\n", 1) = 1sendto(7, "<28>Feb 3 11:48:42 puppet-agent"..., 143, MSG_NOSIGNAL, NULL, 0) = 143stat("/usr/bin/useradd", 0x7ffd573a3f70) = -1 ENOENT (No such file or directory)stat("/bin/useradd", 0x7ffd573a3f70)= -1 ENOENT (No such file or directory)stat("/usr/sbin/useradd", {st_mode=S_IFREG|0750, st_size=114064, ...}) = 0stat("/usr/sbin/useradd", {st_mode=S_IFREG|0750, st_size=114064, ...}) = 0{noformat} Add Comment
Jira (PUP-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg updated an issue Puppet / PUP-5808 puppet via sudo from nfs home is not working Change By: Adam Winberg We use NFS mounted home directories for all our users. If a sysadmin or devop wants to trigger a puppet agent run via sudo, he/she must change dir from the nfs home directory to a local directory, otherwise the puppet run will fail. This is nothing new, but I'd like to know if it is intended behaviour or if it is something that could be fixed. So, running an strace on the puppet agent run, I see that puppet executes repeatedly executes a 'chdir' to the cwd. These chdirs are typically performed before a stat operation to get the correct path for a provider (i.e. /usr/bin/mount or /usr/local/sbin/mount). When running via sudo from my homedir, this fails since root has no permissions to enter that directory. I can work around this by cd'ing to a local dir before running 'sudo puppet', or invoking sudo with the '-i' flag, but to make it failsafe for our devops it would be better if they didnt have to think about that. I would suggest to use the default tempdir of the system (linux=/tmp) instead of the cwd for these chdir operations. But I probably fail to see the complete picture. Outtake from strace log:{noformat}chdir("/home/a001329") = -1 EACCES (Permission denied)write(2, "\33[1;31mError: /Stage[pre]/Core::"..., 137^[[1;31mError: /Stage[pre]/Core::Users::Update_root_pw/Exec[set_grub2_password]: Could not evaluate: Permission denied - /home/a001329^[[0m) = 137write(2, "\n", 1) = 1sendto(7, "<27>Feb 3 11:48:42 puppet-agent"..., 161, MSG_NOSIGNAL, NULL, 0) = 161write(1, "\33[mNotice: /Stage[pre]/Core::Use"..., 131^[[mNotice: /Stage[pre]/Core::Users::Update_root_pw/Exec[grub2-mkconfig]: Dependency Exec[set_grub2_password] has failures: true^[[0m) = 131write(1, "\n", 1) = 1sendto(7, "<29>Feb 3 11:48:42 puppet-agent"..., 158, MSG_NOSIGNAL, NULL, 0) = 158write(2, "\33[1;31mWarning: /Stage[pre]/Core"..., 121^[[1;31mWarning: /Stage[pre]/Core::Users::Update_root_pw/Exec[grub2-mkconfig]: Skipping because of failed dependencies^[[0m) = 121write(2, "\n", 1) = 1sendto(7, "<28>Feb 3 11:48:42 puppet-agent"..., 143, MSG_NOSIGNAL, NULL, 0) = 143stat("/usr/bin/useradd", 0x7ffd573a3f70) = -1 ENOENT (No such file or directory)stat("/bin/useradd", 0x7ffd573a3f70)= -1 ENOENT (No such file or directory)stat("/usr/sbin/useradd", {st_mode=S_IFREG|0750, st_size=114064, ...}) = 0stat("/usr/sbin/useradd", {st_mode=S_IFREG|0750, st_size=114064, ...}) = 0{noformat} Add Comment
Jira (PUP-5808) puppet via sudo from nfs home is not working
Title: Message Title Adam Winberg created an issue Puppet / PUP-5808 puppet via sudo from nfs home is not working Issue Type: Bug Affects Versions: PUP 3.8.4 Assignee: Kylo Ginsberg Components: Types and Providers Created: 2016/02/03 8:07 AM Environment: RHEL7.2, RHEL6.7 puppet-3.8.4-1.el7.noarch, puppet-3.8.4-1.el6.noarch Priority: Normal Reporter: Adam Winberg We use NFS mounted home directories for all our users. If a sysadmin or devop wants to trigger a puppet agent run via sudo, he/she must change dir from the nfs home directory to a local directory, otherwise the puppet run will fail. This is nothing new, but I'd like to know if it is intended behaviour or if it is something that could be fixed. So, running an strace on the puppet agent run, I see that puppet executes repeatedly executes a 'chdir' to the cwd. These chdirs are typically performed before a stat operation to get the correct path for a provider (i.e. /usr/bin/mount or /usr/local/sbin/mount). When ru
Jira (PUP-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection I'm using puppetserver 1.1.1, which has a dependency (i'm on RHEL) to java-1.7.0-openjdk (of which I am running latest patch), so thats the one I'm using. It's no problem for me to run java8 instead, though. I'm gonna do some more digging regarding networking and such. I'll get back to you about that updated jetty build. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection I'm also seeing the occasional WARN [o.e.j.s.HttpChannel] Could not send response error 500: java.lang.IllegalStateException: org.eclipse.jetty.util.SharedBlockingCallback$BlockerTimeoutException message in the puppetserver.log when agent runs are aborted. Then I found this jetty bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=444031 Don't know if thats relevant with the jetty version puppetserver is using, but it sounds like it may be a similar problem. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection Using apache/passenger I have only had one puppet run where ~70 agent runs failed. It's still really slow at those times, but manage to keep it together more so than puppetserver (with my current configuration). The only parameters in the jetty config docs you provided that seem interesting to me is the idleTimeout and the stopTimeout. The former I believe is already set (idle-timeout-milliseconds), but the latter may be interesting, is this already available and what's its default value? Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection right now I have reverted back to apache/passenger just to confirm that this plays nicer than puppetserver in my env. Gonna let this run for a day or two. I do prefer the puppetserver jvm approach though, less moving parts and thus easier to manage - provided it works, of course. Reproducing is hard. Well, not for me, I just have to wait a couple of hours, but since I can't properly define why my puppetserver gets into trouble in the first place it's not that easy for you guys to debug. Undeniably there is a lot of congestion on the puppetserver at some times, with catalog requests building up far faster than puppetserver can manage to serve them. I'm gonna think about networking some more. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection no, no load balancer. I use foreman as ENC and for reporting. I am still trying to pinpoint where the problem lies, I do believe its inherent to some overall infrastructure load in our environment, but since apache/passenger managed to get the job done i would think puppetserver should too. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection I don't see any timeout values at play here. For example I have two nodes which started their agent runs at different times (one minute apart) but both terminated with "end of file reached" at the same second. Logs from puppet agents: Oct 18 16:09:09 lxserv363 puppet-agent[62991]: Retrieving pluginfacts Oct 18 16:09:54 lxserv363 puppet-agent[62991]: Retrieving plugin Oct 18 16:10:34 lxserv363 puppet-agent[62991]: Loading facts Oct 18 16:10:34 lxserv363 puppet-agent[62991]: Loading facts Oct 18 16:12:33 lxserv363 puppet-agent[62991]: Could not retrieve catalog from remote server: end of file reached Oct 18 16:08:15 lxserv1055 puppet-agent[16951]: Retrieving pluginfacts Oct 18 16:08:27 lxserv1055 puppet-agent[16951]: Retrieving plugin
Jira (PUP-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on PUP-3238 Re: puppet reports "end of file reached" if server closes HTTP connection I have switched from apache/passenger to puppetserver and also get this intermittently. The problem arise during certain times when our nfs server is under heavy load, and since we serve our modules from nfs the puppet runs are generally quite slow during these times. However, apache/passenger could cope just fine with this, slower runs but no timeouts, and I hope I can configure puppetserver to do this too. Unfortunately, increasing idle-timeout-milliseconds to 40min had no effect, the "java.nio.channels.WritePendingException: null" and "end of file reached" messages appears at the same time as before. I also set connect-timeout-milliseconds to 5min, but no effect. Any ideas? Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 Henrik Lindberg] yeah, of course. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 no probs, happy to help (since I'm not paying for PE, it's the least I can do - it's an awesome software), plus I got my puppetserver working. (and I learned about git bisect) Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 Updated to 3.8.2 and applied the same patch, works swimmingly. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 whoa, yeah, I patched so "def self.future_parser?" returns false and nothing else, commenting out all other code, and this 'fixed' the problem. My compilation speeds are totally comparable with 3.7.4 with this patched 3.7.5. So, how come I'm hitting this so hard and noone else? Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 'git bisect' is really cool! Really helpful tool, I must say. Anyways, this is the results: b14075fbaeb9c8bab167aa8aed0635efe7d11ce4 is the first bad commit commit b14075fbaeb9c8bab167aa8aed0635efe7d11ce4 Author: Hailee Kenney Date: Thu Feb 19 15:37:40 2015 -0800 (PUP-4017) Make parser an environment specific setting Prior to this commit, the 'parser' setting was not environment specific. In order to make it easier for users to migrate to using the future parser, make 'parser' environment specific.
Jira (PUP-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 I used mcollective to trigger an agent run on 5 nodes with a 10s splay. I did this twice for each iteration. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 About jruby instances: If I run a single agent against a 3.7.5 master the catalog run is pretty fast - 5-10s. Not as fast as 3.7.4, but considerably faster than the 40-100s the catalog run takes if I put some load on it (i.e 80 agents running with splay 60s). Also, a single agent run is considerably faster if I use a single jruby instance compared with using 10 instances, which is a bit odd. Of course, if I put a bit of load on it with only 1 jruby instance the server gets really slow. Somehow for each jruby instance I add, each agent run gets a bit slower. Running with 1 jruby instance, 5 agent runs with 10s splay = 5-10s catalog compilation time Running with 3 jruby instance, 5 agent runs with 10s splay = 5-15s catalog compilation time Running with 10 jruby instance, 5 agent runs with 10s splay = 50-70s catalog compilation time The 'git bisect' thing sounds cool and would probably show us the problem. I would gladly accept some pointers on which git branches to check out. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 nope, no future parser yet. I will post some more info on behaviour with different number of jruby instances, to me it seems a bit fishy. Just need to wait for the current puppet run to finish before starting testing again... Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 unfortunately no difference in performance with filetimeout set. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 I gave it a quick go, but am running into problem even starting the puppetserver service So I have the feeling it could be some hard work getting to the point where I can have reliable test results with catalogs with puppet4. It's also a more disruptive test since puppet4 packages obsoletes the old packages (thus removing them) which makes it harder to revert to a working state. Maybe I can fiddle with puppet4 in a test environment if I find the time, but if we at the mean time could explore some other options for debugging that would be great. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-5380) Slow catalog run after updating to puppet 3.7.5
Title: Message Title Adam Winberg commented on PUP-5380 Re: Slow catalog run after updating to puppet 3.7.5 We've put off upgrading to puppet4 since Foreman does not fully support it yet, so its completely untested here. But I guess I can give it a go. Might be some time though, as I said we havent started tested our code with v4 yet so I anticipate some problems. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- 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-3337) Validation of shell in user resource breaks when using sudo
Title: Message Title Adam Winberg created an issue Puppet / PUP-3337 Validation of shell in user resource breaks when using sudo Issue Type: Bug Affects Versions: 3.7.0 Assignee: Kylo Ginsberg Components: Client Created: 24/Sep/14 9:03 AM Priority: Normal Reporter: Adam Winberg We have an special user on our clients used to allow emergency logins if the user has lost his/hers smartcard. This user has a loginshell like this: "/usr/bin/sudo /usr/bin/emerg.sh" This worked fine before, but somewhere along the way a validation of the shell has been introduced which renders the error: "Shell /usr/bin/sudo /usr/bin/emerg.sh must exist" Add Comment
Jira (PUP-3238) puppet reports "end of file reached" if server closes HTTP connection
Title: Message Title Adam Winberg commented on an issue Re: puppet reports "end of file reached" if server closes HTTP connection I understand the difficulties in providing a 'better' error message, so updated docs is good enough for me. Here's the trace: Info: Retrieving pluginfacts Info: Retrieving plugin Info: Loading facts Error: Could not retrieve catalog from remote server: end of file reached /usr/lib/ruby/1.8/net/protocol.rb:135:in `sysread' /usr/lib/ruby/1.8/net/protocol.rb:135:in `rbuf_fill' /usr/lib/ruby/1.8/timeout.rb:67:in `timeout' /usr/lib/ruby/1.8/timeout.rb:101:in `timeout' /usr/lib/ruby/1.8/net/protocol.rb:134:in `rbuf_fill' /usr/lib/ruby/1.8/net/protocol.rb:116:in `readuntil' /usr/lib/ruby/1.8/net/protocol.rb:126:in `readline' /usr/lib/ruby/1.8/net/http.rb:2028:in `read_status_line' /usr/lib/ruby/1.8/net/http.rb:2017:in `read_new' /usr/lib/ruby/1.8/net/http.rb:1051:in `request' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:208:in `execute_request' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:176:in `request_with_redirects' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:219:in `with_connection' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/pool.rb:31:in `with_connection' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:218:in `with_connection' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:173:in `request_with_redirects' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:170:in `upto' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:170:in `request_with_redirects' /usr/lib/ruby/site_ruby/1.8/puppet/network/http/connection.rb:87:in `post' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:83:in `send' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:83:in `http_request' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:66:in `http_post' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:94:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:190:in `do_request' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/request.rb:264:in `do_request' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:190:in `do_request' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/rest.rb:90:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/indirector/indirection.rb:201:in `find' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:289:in `retrieve_new_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:327:in `thinmark' /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime' /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:326:in `thinmark' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:288:in `retrieve_new_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:61:in `retrieve_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:104:in `prepare_and_retrieve_catalog' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:201:in `run_internal' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:132:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/context.rb:64:in `override' /usr/lib/ruby/site_ruby/1.8/puppet.rb:244:in `override' /usr/lib/ruby/site_ruby/1.8/puppet/configurer.rb:131:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:47:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent/locker.rb:20:in `lock' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:47:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:117:in `with_client' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:44:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:82:in `run_in_fork' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:43:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:179:in `call' /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:179:in `controlled_run' /usr/lib/ruby/site_ruby/1.8/puppet/agent.rb:41:in `run' /usr/lib/ruby/site_ruby/1.8/puppet/application/agent.rb:356:in `onetime' /usr/lib/ruby/site_ruby/1
Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name
Title: Message Title Adam Winberg commented on an issue Re: puppet crashes if there are multiple pluginsync files with same name Also forgot to mention, this happens on RHEL6 hosts but not RHEL7. So what's different there? The http_keepalive_timeout is set to 4 in both instances and they connect to the same puppetmaster. Add Comment Puppet / PUP-3238 puppet crashes if there are multiple pluginsync files with same name I have two dirname.rb functions in my code, one from stdlib and one in a different module I installed at an earlier stage. This has never been a problem, puppet has somehow chosen one of them and not complained about it. After upgrading to 3.7.0 on the clients, the puppetruns crashes with "Error: Could not retrieve catalog from remote server: end of file... 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
Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name
Title: Message Title Adam Winberg commented on an issue Re: puppet crashes if there are multiple pluginsync files with same name ok, so I had a KeepAliveTimeout setting of '1' in apache on my puppetmaster. Setting this to '5', to be higher than puppets 'http_keepalive_timeout' default setting of 4s, solves the problem. I do however think that, if possible, there should be a error message indicating this problem more clearly. Add Comment Puppet / PUP-3238 puppet crashes if there are multiple pluginsync files with same name I have two dirname.rb functions in my code, one from stdlib and one in a different module I installed at an earlier stage. This has never been a problem, puppet has somehow chosen one of them and not complained about it. After upgrading to 3.7.0 on the clients, the puppetruns crashes with "Error: Could not retrieve catalog from remote server: end of file... 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
Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name
Title: Message Title Adam Winberg commented on an issue Re: puppet crashes if there are multiple pluginsync files with same name I spoke to soon... Removing, or rather making a change in the plugins, made the puppetrun work once, but the following run fails with the same error. Add Comment Puppet / PUP-3238 puppet crashes if there are multiple pluginsync files with same name I have two dirname.rb functions in my code, one from stdlib and one in a different module I installed at an earlier stage. This has never been a problem, puppet has somehow chosen one of them and not complained about it. After upgrading to 3.7.0 on the clients, the puppetruns crashes with "Error: Could not retrieve catalog from remote server: end of file... 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, vi
Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name
Title: Message Title Adam Winberg created an issue Puppet / PUP-3238 puppet crashes if there are multiple pluginsync files with same name Issue Type: Bug Affects Versions: 3.7.0 Assignee: Kylo Ginsberg Components: Client Created: 12/Sep/14 12:05 AM Priority: Normal Reporter: Adam Winberg I have two dirname.rb functions in my code, one from stdlib and one in a different module I installed at an earlier stage. This has never been a problem, puppet has somehow chosen one of them and not complained about it. After upgrading to 3.7.0 on the clients, the puppetruns crashes with "Error: Could not retrieve catalog from remote server: end of file reached" using --debug parameter did not make the reasons for this any clearer and I have not found any documentation in release notes about this. I think this change should be included in release notes and there should be a clearer error message about it.