Jira (FACT-1907) facter 3.12.2 choses wrong ip as main ip

2022-08-17 Thread Adam Winberg (Jira) 
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

2021-01-21 Thread Adam Winberg (Jira) 
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

2021-01-20 Thread Adam Winberg (Jira) 
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

2019-10-15 Thread Adam Winberg (JIRA) 
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

2019-10-11 Thread Adam Winberg (JIRA) 
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

Jira (PUP-9601) mount resource should trigger 'systemctl daemon-reload'

2019-04-24 Thread Adam Winberg (JIRA) 
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'

2019-04-24 Thread Adam Winberg (JIRA) 
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'

2019-04-04 Thread Adam Winberg (JIRA) 
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'

2019-04-03 Thread Adam Winberg (JIRA) 
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'

2019-04-03 Thread Adam Winberg (JIRA) 
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

2019-01-10 Thread Adam Winberg (JIRA) 
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

2018-08-14 Thread Adam Winberg (JIRA) 
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

2017-03-09 Thread Adam Winberg (JIRA) 
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

2017-03-09 Thread Adam Winberg (JIRA) 
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

2017-03-09 Thread Adam Winberg (JIRA) 
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

Jira (PUP-6339) Hiera Data in Module give bad results when environment_timeout is unlimited

2017-03-09 Thread Adam Winberg (JIRA) 
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

2017-03-09 Thread Adam Winberg (JIRA) 
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

2017-03-09 Thread Adam Winberg (JIRA) 
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

2017-03-09 Thread Adam Winberg (JIRA) 
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

2017-03-08 Thread Adam Winberg (JIRA) 
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

2017-03-08 Thread Adam Winberg (JIRA) 
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

2017-02-08 Thread Adam Winberg (JIRA) 
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

2016-08-31 Thread Adam Winberg (JIRA) 
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

2016-08-31 Thread Adam Winberg (JIRA) 
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

2016-08-31 Thread Adam Winberg (JIRA) 
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

2016-02-03 Thread Adam Winberg (JIRA) 
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

2016-02-03 Thread Adam Winberg (JIRA) 
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

2016-02-03 Thread Adam Winberg (JIRA) 
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

Jira (PUP-3238) puppet reports "end of file reached" if server closes HTTP connection

2015-10-23 Thread Adam Winberg (JIRA) 
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

2015-10-23 Thread Adam Winberg (JIRA) 
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

2015-10-23 Thread Adam Winberg (JIRA) 
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

2015-10-20 Thread Adam Winberg (JIRA) 
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

2015-10-19 Thread Adam Winberg (JIRA) 
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

2015-10-19 Thread Adam Winberg (JIRA) 
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-5380) Slow catalog run after updating to puppet 3.7.5

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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-5380) Slow catalog run after updating to puppet 3.7.5

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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-3238) puppet reports "end of file reached" if server closes HTTP connection

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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

2015-10-15 Thread Adam Winberg (JIRA) 
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-3337) Validation of shell in user resource breaks when using sudo

2014-09-24 Thread Adam Winberg (JIRA) 
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

2014-09-15 Thread Adam Winberg (JIRA) 
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'

Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name

2014-09-12 Thread Adam Winberg (JIRA) 
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.

Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name

2014-09-12 Thread Adam Winberg (JIRA) 
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, visit

Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name

2014-09-12 Thread Adam Winberg (JIRA) 
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 to

Jira (PUP-3238) puppet crashes if there are multiple pluginsync files with same name

2014-09-12 Thread Adam Winberg (JIRA) 
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