[Facter - Bug #21530] cfpropertylist .to_plist method doesn't output Apple standard XML format

2013-09-19 Thread tickets

Issue #21530 has been updated by Christian Kruse.


You are right, there was a bug. I fixed it in latest HEAD. As soon as it has 
been confirmed to be working, I will release a new version.


Bug #21530: cfpropertylist .to_plist method doesn't output Apple standard XML 
format
https://projects.puppetlabs.com/issues/21530#change-97778

* Author: Clay Caviness
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected Facter version: 

The output when using FORMAT_XML isn't in Apple style, with tab indention, but 
is instead all on one line. While this is valid XML, it's not pretty. We 
generally like to write XML plists and not binary, as they're simpler to read 
without extra tools.


$ ruby -r facter -r facter/util/plist -e "p = {'foo'=>'bar', 
'baz'=>[1,2,3]}.to_plist(); puts p"

;


  baz
  
1
2
3
  
  foo
  bar


$ facter --version
1.6.2
$ sudo pkgutil --forget com.reductivelabs.facter
Forgot package 'com.reductivelabs.facter' on '/'.
$ sudo installer -target / -pkg /Volumes/facter-1.7.1/facter-1.7.1.pkg
installer: Package name is facter-1.7.1
installer: Installing at base path /
installer: The install was successful.
$ ruby -r facter -r facter/util/cfpropertylist -e "p = {'foo'=>'bar', 
'baz'=>[1,2,3]}.to_plist({:plist_format=>2}); puts p"

;
baz123foobar
$ facter --version
1.7.1



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Feature #21241] (In Topic Branch Pending Review) Add the ability to specify the nice/priority level of puppet

2013-09-19 Thread tickets

Issue #21241 has been updated by Josh Cooper.

Status changed from Accepted to In Topic Branch Pending Review
Target version set to 3.4.0
Branch changed from 
https://github.com/joshcooper/puppet/tree/ticket/stable/21241-priority to 
https://github.com/puppetlabs/puppet/pull/1922


Feature #21241: Add the ability to specify the nice/priority level of puppet
https://projects.puppetlabs.com/issues/21241#change-9

* Author: Josh Cooper
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.4.0
* Affected Puppet version: 
* Keywords: windows
* Branch: https://github.com/puppetlabs/puppet/pull/1922

On *nix, the init script can be modified to run puppet agents at a specified 
priority level: `nice [-n increment] puppet agent`. See #1381 for more 
discussion about this. However, this doesn't work on windows using built-in 
commands.

A customer has requested the ability to specify the priority level as a 
configuration setting. The reasoning is that they have time sensitive 
operations and don't want puppet agents to take CPU cycles from these other 
tasks.

On Windows, the process priority can be set via 
[SetPriorityClass](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686219(v=vs.85\).aspx),
 and on POSIX systems `setpriority`.

Additionally, we may want to restrict the number of processors that puppet is 
allowed to run on, e.g. 
[SetPriorityAffinityMask](http://msdn.microsoft.com/en-us/library/windows/desktop/ms686223(v=vs.85\).aspx),
 though puppet agents are not multi-threaded, so that may not really be 
necessary.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #21608] (Closed) Syntax error at '}'; expected '}'

2013-09-19 Thread tickets

Issue #21608 has been updated by Henrik Lindberg.

Status changed from Needs Decision to Closed

I tried this in the future parser:

Syntax error at '}' at ./foo.pp:8:75


Indicating that the parser does not know what to do at the very final `}`.

It is unfortunately impossible to differentiate between the two cases:
* a function call of function f with a hash as an argument (with an array as a 
key, missing a => and a value), which BTW is illegal since an array is not 
valid hash key
* a resource expression creating an instance of a resource of type F with a 
title being an array, but missing a colon.

This is very difficult to anything about - the parser technology is not smart 
enough to report what would make it happy at that point. It only announce its 
unhappiness when seeing the final `}´.

In order to be able to give a better error message the parser would need to be 
able to accept an expression block - i.e.


'{' expression '}'


This is however not easily introduced because of the ambiguities it creates - 
we would need to relax the grammar substantially and move the complexity 
elsewhere. 
IMO, the distinction between a literal hash and a resource expression is one of 
the harder to solve ambiguities in the language and was one of the difficult 
things to handle when being able to
use literal hashes everywhere a value is allowed.

It may still be solvable, effort is not known.

When giving the same logic to Geppetto and trying it with 3.2 and with future 
langauge versions - it gives a series of errors:

* Not a top level expression (the entire expression
* missing } at [
* extranous input }, expecting EOF
* Unknown function 'f'

If the final comma in the title array is removed, it also gives this problem:
* A resource reference must start with a [(deprecated) name, or] class 
reference. (i.e. this is given because the LHS before the [] is not a name (it 
is an error), it could have been f['foo'].

>From that it is possible to figure out that the expression clearly is highly 
>ambiguous (which we sort of knew already), but it tells us that 'f' is an 
>unknown function - so clearly what follows is not recognized as a resource 
>(body/bodies) expression. I.e. the function 'f' is the last piece it can make 
>sense of. 

This is pretty much the same as what happens in the puppet parser.

To summarize. The ':' is a darned important clue to the parser what is actually 
being expressed, and it is almost impossible to make it suggest a missing ':' 
as being the problem simply because it does not know that is the problem.

IMO, the detailed position information from future parser - or using Geppetto 
which tries more options is as good as it gets without either a very large 
effort (possible not being able to fix it), or changing the language itself.

I am therefore marking this issue as closed. There is no "works as best as it 
can in future version"- status to set.

There may be a greater chance in improving the error message in Geppetto 
(different parser technology), but I still think it is going to be hard because 
of the fundamental problem "is it a hash" or a "resource expression".



Bug #21608: Syntax error at '}'; expected '}'
https://projects.puppetlabs.com/issues/21608#change-97776

* Author: Chris Wilson
* Status: Closed
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: language
* Target version: 
* Affected Puppet version: 2.6.18
* Keywords: parser errors
* Branch: 

>From the following code:


  # 
http://stackoverflow.com/questions/6399922/are-there-iterators-and-loops-in-puppet
  define f {
file { "/root/.ssh/${title}":
  ensure => present,
  source => 'puppet:///files/ssh_keys/${title}',
  owner   => 'root', group => 'root', mode => '0400',
}
  }
  f { ["id_beep_down", "id_beep_down.pub", "id_beep_up", "id_beep_up.pub",] }


I think it's missing a colon after the last ], but that's not what the error 
message says.


[puppet server]$ rpm -q puppet
puppet-2.6.18-3.el6.noarch



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Facter - Bug #22619] Error when NetConnectionId is missing on NetworkAdapter

2013-09-19 Thread tickets

Issue #22619 has been updated by Josh Cooper.

Description updated


Bug #22619: Error when NetConnectionId is missing on NetworkAdapter
https://projects.puppetlabs.com/issues/22619#change-97775

* Author: Rob Reynolds
* Status: Investigating
* Priority: Normal
* Assignee: Rob Reynolds
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: 
* Affected Facter version: 1.7.3

When someone has a network configuration that has IPEnabled set to true, it 
doesn't necessarily mean the Network Adapter behind it also has IPEnabled set 
to true. The latest release of facter (1.7.3) introduced a bug that causes 
puppet to error when gathering facts about the interfaces if someone has such a 
configuration on their system.

Output from WMI queries on an affected system:  

 - https://gist.github.com/anonymous/15c1e09eca5b7c42e29e
 - https://gist.github.com/anonymous/810f922a3a40bfbe863f

Match each of them up by Index (as we do here: 
https://github.com/puppetlabs/facter/blob/stable/lib/facter/util/ip/windows.rb#L46-L47
 )

 - Index=7 (Server_LAN)
 - Index=12 (Replication)
 - Index=14 (Backup-LAN)
 - Index=16 (no NetConnectionID) (the network config has IPEnabled, but the 
adapter does not)

The offender is "Microsoft Failover Cluster Virtual Adapter"


C:\puppet\bin>puppet agent --test --debug --trace 
Error: Could not retrieve local facts: undefined method `gsub' for nil:NilClass
C:/puppet/facter/lib/facter/util/ip.rb:39:in `alphafy'
C:/puppet/facter/lib/facter/interfaces.rb:35:in `block (2 levels) in '
C:/puppet/facter/lib/facter/interfaces.rb:34:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:34:in `block in '
C:/puppet/facter/lib/facter/interfaces.rb:29:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:29:in `'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load_file'
C:/puppet/facter/lib/facter/util/loader.rb:46:in `block (2 levels) in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `block in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `load_all'
C:/puppet/facter/lib/facter/util/collection.rb:114:in `load_all'
C:/puppet/facter/lib/facter.rb:248:in `loadfacts'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:11:in `reload_facter'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:53:in `find'
C:/puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:15:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
C:/puppet/puppet/lib/puppet/agent.rb:42:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:84:in `run_in_fork'
C:/puppet/puppet/lib/puppet/agent.rb:41:in `block in run'
C:/puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/puppet/puppet/lib/puppet/util.rb:511:in `exit_on_fail'
C:/puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/puppet/puppet/bin/puppet:4:in `
' Error: Failed to apply catalog: Could not retrieve local facts: undefined method `gsub' for nil:NilClass C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:26:in `rescue in find_facts' C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:14:in `find_facts' C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in `facts_for_uploading' C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts' C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run' C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run' C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock' C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run' C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize' C:/puppet/puppet/lib/puppet

[Puppet - Bug #22608] (Merged - Pending Release) filebucket (backup) does not work with 3.3.0 master and older clients

2013-09-19 Thread tickets

Issue #22608 has been updated by Josh Partlow.

Status changed from In Topic Branch Pending Review to Merged - Pending Release

Merged to stable in d7e1ee3.  Should be released in 3.3.1


Bug #22608: filebucket (backup) does not work with 3.3.0 master and older 
clients
https://projects.puppetlabs.com/issues/22608#change-97773

* Author: Bernhard Schmidt
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.3.1
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/1919

After upgrading the master to 3.3.0 backing up changed files from older clients 
does not work anymore.

2013-09-18 16:31:06 + /File[/etc/ferm/ferm.d/20-funcs.ferm]/content 
(err): change from {md5}66618d21aa5f26e836a171cc07c038a4 to 
{md5}ec8100f38c6f882eff001a3e6b67385c failed: Could not back up 
/etc/ferm/ferm.d/20-funcs.ferm: Error 406 on SERVER: Not Acceptable: No 
supported formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)

Setting the report_serialization_format setting to yaml does not seem to help 
here.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #21608] (Needs Decision) Syntax error at '}'; expected '}'

2013-09-19 Thread tickets

Issue #21608 has been updated by eric sorenson.

Status changed from Investigating to Needs Decision
Assignee set to Henrik Lindberg

Whups, I forgot to actually set this to your ownership, Henrik, when I asked a 
question.


Bug #21608: Syntax error at '}'; expected '}'
https://projects.puppetlabs.com/issues/21608#change-97766

* Author: Chris Wilson
* Status: Needs Decision
* Priority: Normal
* Assignee: Henrik Lindberg
* Category: language
* Target version: 
* Affected Puppet version: 2.6.18
* Keywords: parser errors
* Branch: 

>From the following code:


  # 
http://stackoverflow.com/questions/6399922/are-there-iterators-and-loops-in-puppet
  define f {
file { "/root/.ssh/${title}":
  ensure => present,
  source => 'puppet:///files/ssh_keys/${title}',
  owner   => 'root', group => 'root', mode => '0400',
}
  }
  f { ["id_beep_down", "id_beep_down.pub", "id_beep_up", "id_beep_up.pub",] }


I think it's missing a colon after the last ], but that's not what the error 
message says.


[puppet server]$ rpm -q puppet
puppet-2.6.18-3.el6.noarch



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #17030] pip provider should handle multiple pips/pythons

2013-09-19 Thread tickets

Issue #17030 has been updated by Josh Cooper.

Affected Puppet version changed from 3.3.0 to 2.6.17

Please keep the affected version as the earliest known version the issue exists 
in.


Bug #17030: pip provider should handle multiple pips/pythons
https://projects.puppetlabs.com/issues/17030#change-97754

* Author: Bradley Kreider
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: provider
* Target version: 
* Affected Puppet version: 2.6.17
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/1486

The Pip provider should provide a way to specify the path to pip.  This would 
allow people to manage multiple python installs, by point to the one they want 
to install into.  

In RHEL, this makes it easy to have a non-system python installed somewhere 
(ie: 2.7 or 3.x) and let puppet manage the python packages.

This is related to bug #15980.  (related in the way that if you could provide 
the path to the pip binary, 15980 would have a workaround).


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Facter - Bug #22619] (Investigating) Error when NetConnectionId is missing on NetworkAdapter

2013-09-19 Thread tickets

Issue #22619 has been updated by Rob Reynolds.

Description updated
Status changed from Unreviewed to Investigating
Assignee set to Rob Reynolds


Bug #22619: Error when NetConnectionId is missing on NetworkAdapter
https://projects.puppetlabs.com/issues/22619#change-97770

* Author: Rob Reynolds
* Status: Investigating
* Priority: Normal
* Assignee: Rob Reynolds
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: 
* Affected Facter version: 1.7.3

When someone has a network configuration that has IPEnabled set to true, it 
doesn't necessarily mean the Network Adapter behind it also has IPEnabled set 
to true. The latest release of facter (1.7.3) introduced a bug that causes 
puppet to error when gathering facts about the interfaces if someone has such a 
configuration on their system.

Output from WMI queries on an affected system:  

 - https://gist.github.com/anonymous/15c1e09eca5b7c42e29e
 - https://gist.github.com/anonymous/810f922a3a40bfbe863f

Match each of them up by Index (as we do here: 
https://github.com/puppetlabs/facter/blob/stable/lib/facter/util/ip/windows.rb#L46-L47
 )

 - Index=7 (Server_LAN)
 - Index=12 (Replication)
 - Index=14 (Backup-LAN)
 - Index=16 (no NetConnectionID) (the network config has IPEnabled, but the 
adapter does not)

The offender is "Microsoft Failover Cluster Virtual Adapter"

C:\puppet\bin>puppet agent --test --debug --trace 

Error: Could not retrieve local facts: undefined method `gsub' for nil:NilClass
C:/puppet/facter/lib/facter/util/ip.rb:39:in `alphafy'
C:/puppet/facter/lib/facter/interfaces.rb:35:in `block (2 levels) in '
C:/puppet/facter/lib/facter/interfaces.rb:34:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:34:in `block in '
C:/puppet/facter/lib/facter/interfaces.rb:29:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:29:in `'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load_file'
C:/puppet/facter/lib/facter/util/loader.rb:46:in `block (2 levels) in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `block in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `load_all'
C:/puppet/facter/lib/facter/util/collection.rb:114:in `load_all'
C:/puppet/facter/lib/facter.rb:248:in `loadfacts'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:11:in `reload_facter'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:53:in `find'
C:/puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:15:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
C:/puppet/puppet/lib/puppet/agent.rb:42:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:84:in `run_in_fork'
C:/puppet/puppet/lib/puppet/agent.rb:41:in `block in run'
C:/puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/puppet/puppet/lib/puppet/util.rb:511:in `exit_on_fail'
C:/puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/puppet/puppet/bin/puppet:4:in `'
Error: Failed to apply catalog: Could not retrieve local facts: undefined 
method `gsub' for nil:NilClass
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:26:in `rescue in 
find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:14:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/

[Facter - Bug #22619] Error when NetConnectionId is missing on NetworkAdapter

2013-09-19 Thread tickets

Issue #22619 has been updated by Rob Reynolds.

Description updated


Bug #22619: Error when NetConnectionId is missing on NetworkAdapter
https://projects.puppetlabs.com/issues/22619#change-97769

* Author: Rob Reynolds
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: 
* Affected Facter version: 1.7.3

When someone has a network configuration that has IPEnabled set to true, it 
doesn't necessarily mean the Network Adapter behind it also has IPEnabled set 
to true. The latest release of facter (1.7.3) introduced a bug that causes 
puppet to error when gathering facts about the interfaces if someone has such a 
configuration on their system.

Output from WMI queries on affected system: 
 - https://gist.github.com/anonymous/15c1e09eca5b7c42e29e
 - https://gist.github.com/anonymous/810f922a3a40bfbe863f

Match each of them up by Index (as we do here: 
https://github.com/puppetlabs/facter/blob/stable/lib/facter/util/ip/windows.rb#L46-L47
 )

 - Index=7 (Server_LAN)
 - Index=12 (Replication)
 - Index=14 (Backup-LAN)
 - Index=16 (no NetConnectionID) (the network config has ipenabled, but the 
adapter does not)

The offender is "Microsoft Failover Cluster Virtual Adapter"

C:\puppet\bin>puppet agent --test --debug --trace 

Error: Could not retrieve local facts: undefined method `gsub' for nil:NilClass
C:/puppet/facter/lib/facter/util/ip.rb:39:in `alphafy'
C:/puppet/facter/lib/facter/interfaces.rb:35:in `block (2 levels) in '
C:/puppet/facter/lib/facter/interfaces.rb:34:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:34:in `block in '
C:/puppet/facter/lib/facter/interfaces.rb:29:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:29:in `'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load_file'
C:/puppet/facter/lib/facter/util/loader.rb:46:in `block (2 levels) in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `block in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `load_all'
C:/puppet/facter/lib/facter/util/collection.rb:114:in `load_all'
C:/puppet/facter/lib/facter.rb:248:in `loadfacts'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:11:in `reload_facter'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:53:in `find'
C:/puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:15:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
C:/puppet/puppet/lib/puppet/agent.rb:42:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:84:in `run_in_fork'
C:/puppet/puppet/lib/puppet/agent.rb:41:in `block in run'
C:/puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/puppet/puppet/lib/puppet/util.rb:511:in `exit_on_fail'
C:/puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/puppet/puppet/bin/puppet:4:in `'
Error: Failed to apply catalog: Could not retrieve local facts: undefined 
method `gsub' for nil:NilClass
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:26:in `rescue in 
find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:14:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3

[Facter - Bug #22619] (Unreviewed) Error when NetConnectionId is missing on NetworkAdapter

2013-09-19 Thread tickets

Issue #22619 has been reported by Rob Reynolds.


Bug #22619: Error when NetConnectionId is missing on NetworkAdapter
https://projects.puppetlabs.com/issues/22619

* Author: Rob Reynolds
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 1.7.4
* Keywords: windows
* Branch: 
* Affected Facter version: 1.7.3

When someone has a network configuration that has IPEnabled set to true, it 
doesn't necessarily mean the Network Adapter behind it also has IPEnabled set 
to true. The latest release of facter (1.7.3) introduced a bug that causes 
puppet to error when gathering facts about the interfaces if someone has such a 
configuration on their system.


https://gist.github.com/anonymous/15c1e09eca5b7c42e29e
https://gist.github.com/anonymous/810f922a3a40bfbe863f

Match each of them up by Index (as we do here: 
https://github.com/puppetlabs/facter/blob/stable/lib/facter/util/ip/windows.rb#L46-L47
 )

 - Index=7 (Server_LAN)
 - Index=12 (Replication)
 - Index=14 (Backup-LAN)
 - Index=16 (no NetConnectionID) (the network config has ipenabled, but the 
adapter does not)

The offender is "Microsoft Failover Cluster Virtual Adapter"

C:\puppet\bin>puppet agent --test --debug --trace 

Error: Could not retrieve local facts: undefined method `gsub' for nil:NilClass
C:/puppet/facter/lib/facter/util/ip.rb:39:in `alphafy'
C:/puppet/facter/lib/facter/interfaces.rb:35:in `block (2 levels) in '
C:/puppet/facter/lib/facter/interfaces.rb:34:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:34:in `block in '
C:/puppet/facter/lib/facter/interfaces.rb:29:in `each'
C:/puppet/facter/lib/facter/interfaces.rb:29:in `'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load'
C:/puppet/facter/lib/facter/util/loader.rb:95:in `load_file'
C:/puppet/facter/lib/facter/util/loader.rb:46:in `block (2 levels) in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:41:in `block in load_all'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `each'
C:/puppet/facter/lib/facter/util/loader.rb:38:in `load_all'
C:/puppet/facter/lib/facter/util/collection.rb:114:in `load_all'
C:/puppet/facter/lib/facter.rb:248:in `loadfacts'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:11:in `reload_facter'
C:/puppet/puppet/lib/puppet/indirector/facts/facter.rb:53:in `find'
C:/puppet/puppet/lib/puppet/indirector/indirection.rb:197:in `find'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:15:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
C:/puppet/puppet/lib/puppet/agent.rb:42:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:84:in `run_in_fork'
C:/puppet/puppet/lib/puppet/agent.rb:41:in `block in run'
C:/puppet/puppet/lib/puppet/application.rb:179:in `call'
C:/puppet/puppet/lib/puppet/application.rb:179:in `controlled_run'
C:/puppet/puppet/lib/puppet/agent.rb:39:in `run'
C:/puppet/puppet/lib/puppet/application/agent.rb:360:in `onetime'
C:/puppet/puppet/lib/puppet/application/agent.rb:326:in `run_command'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block (2 levels) in run'
C:/puppet/puppet/lib/puppet/application.rb:457:in `plugin_hook'
C:/puppet/puppet/lib/puppet/application.rb:364:in `block in run'
C:/puppet/puppet/lib/puppet/util.rb:511:in `exit_on_fail'
C:/puppet/puppet/lib/puppet/application.rb:364:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:132:in `run'
C:/puppet/puppet/lib/puppet/util/command_line.rb:86:in `execute'
C:/puppet/puppet/bin/puppet:4:in `'
Error: Failed to apply catalog: Could not retrieve local facts: undefined 
method `gsub' for nil:NilClass
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:26:in `rescue in 
find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:14:in `find_facts'
C:/puppet/puppet/lib/puppet/configurer/fact_handler.rb:31:in 
`facts_for_uploading'
C:/puppet/puppet/lib/puppet/configurer.rb:101:in `get_facts'
C:/puppet/puppet/lib/puppet/configurer.rb:164:in `run'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (5 levels) in run'
C:/puppet/puppet/lib/puppet/agent/locker.rb:20:in `lock'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (4 levels) in run'
C:/puppet/sys/ruby/lib/ruby/1.9.1/sync.rb:227:in `sync_synchronize'
C:/puppet/puppet/lib/puppet/agent.rb:45:in `block (3 levels) in run'
C:/puppet/puppet/lib/puppet/agent.rb:119:in `with_client'
C:/puppe

[Puppet - Bug #5674] (Closed) resource auto-search/auto-loading doesn't work in ruby dsl

2013-09-19 Thread tickets

Issue #5674 has been updated by eric sorenson.

Status changed from Accepted to Closed
Assignee set to eric sorenson

Closing as wont-fix -- the ruby dsl is deprecated and will not receive fixes.


Bug #5674: resource auto-search/auto-loading doesn't work in ruby dsl
https://projects.puppetlabs.com/issues/5674#change-97768

* Author: Yuri Arabadji
* Status: Closed
* Priority: Normal
* Assignee: eric sorenson
* Category: language
* Target version: 
* Affected Puppet version: 2.6.4
* Keywords: 
* Branch: 

It just doesn't work.

.pp:


node 'default' {
testo::seconddef { 'secdef_rsrc': }
}

**notice: Scope(Testo::Seconddef[secdef_rsrc]): Define: second**

while with .rb:


node 'default' do
create_resource 'testo::seconddef', 'secdef_rsrc'
end

**Cannot find definition Testo::Seconddef on node xxx**



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #10547] (Closed) inline_template newlines issue with ruby dsl

2013-09-19 Thread tickets

Issue #10547 has been updated by eric sorenson.

Status changed from Accepted to Closed
Assignee set to eric sorenson

Closing as wont-fix, the ruby dsl is deprecated and will be removed.


Bug #10547: inline_template newlines issue with ruby dsl
https://projects.puppetlabs.com/issues/10547#change-97767

* Author: Matthew Black
* Status: Closed
* Priority: Low
* Assignee: eric sorenson
* Category: language
* Target version: 
* Affected Puppet version: 
* Keywords: ruby dsl
* Branch: 

When using an inline template, it does not like multiline statements.

The following example will throw an erb error when the master tries to compile 
it.

node "default" do
temp = "<% scope.to_hash.keys.each do |k| %>\n<%= k %>\n<% end %>"
file '/tmp/test.txt',
:content => inline_template(temp)
end

If there are no newlines it will compile without issue.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22586] Link does not work: http://links.puppetlabs.com/deprecate_yaml_on_network

2013-09-19 Thread tickets

Issue #22586 has been updated by James Patterson.


It works now for me too. I got a Google login page before.


Bug #22586: Link does not work: 
http://links.puppetlabs.com/deprecate_yaml_on_network
https://projects.puppetlabs.com/issues/22586#change-97765

* Author: James Patterson
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

The link http://links.puppetlabs.com/deprecate_yaml_on_network is not 
accessible. It requires a login.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22557] (Accepted) Regression on arrays and puppet resources using the name attribute

2013-09-19 Thread tickets

Issue #22557 has been updated by Josh Cooper.

Status changed from Unreviewed to Accepted


Bug #22557: Regression on arrays and puppet resources using the name attribute
https://projects.puppetlabs.com/issues/22557#change-97757

* Author: William Van Hevelingen
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Upgraded to Puppet 3.3.0 and started getting these errors.

Reporting broken for arrays on puppet resources using the name attribute.


# puppet apply -e "package { 'nrpe': name => ['nagios-plugins', 
'nagios-nrpe-server'], ensure=>present } "
Notice: Compiled catalog for foo.lan in environment production in 1.72 seconds
Notice: /Stage[main]//Package[nrpe]/ensure: ensure changed 'purged' to 'present'



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #21109] Puppet on windows sometimes crashes

2013-09-19 Thread tickets

Issue #21109 has been updated by Rob Reynolds.


I have a related ticket noted here in the forum - 
https://groups.google.com/forum/#!topic/puppet-users/ZGU9WDhs-40


Bug #21109: Puppet on windows sometimes crashes
https://projects.puppetlabs.com/issues/21109#change-97762

* Author: Josh Cooper
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.1.1
* Keywords: windows
* Branch: 

>From Michael O'Dea:

I noticed that a number of my Windows hosts had stopped dialing in, and upon 
closer inspection I found that Puppet was crashing in Ruby and wevtapi.dll.  I 
can't find any reference to this in the issue tracker, although I've got over a 
dozen occurrences in my environment, all with the same descriptions as below.  
I checked to see if the times were similar, in case the server presented some 
bad data to cause the issue, but the crashes occurred at all different times 
and days.  

My question is, has anyone else seen this?  Is this a known issue?  If it is 
fixed in 3.2.1, can I install 3.2.1 clients against a 3.1.x server?  In the 
meantime, I will be rolling back to an older 2.7.x version that we'd run for 
some time without issue.  

Thanks in advance.  Fault details below.  


Faulting application name: ruby.exe, version: 1.8.7.371, time stamp: 0x5083a46c
Faulting module name: wevtapi.DLL, version: 6.1.7600.16385, time stamp: 
0x4a5bdb2d
Exception code: 0xc005
Fault offset: 0x1360
Faulting process id: 0xa48
Faulting application start time: 0x01ce5e0840c39580
Faulting application path: C:\Program Files (x86)\Puppet 
Labs\Puppet\sys\ruby\bin\ruby.exe
Faulting module path: C:\Windows\system32\wevtapi.DLL
Report Id: 487d9720-c9fc-11e2-8a25-0a252c8f038f



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Feature #22617] (Unreviewed) augeas onlyif comparitor for strings that are integers should do numeric compare

2013-09-19 Thread tickets

Issue #22617 has been reported by Don Law.


Feature #22617: augeas onlyif comparitor for strings that are integers should 
do numeric compare
https://projects.puppetlabs.com/issues/22617

* Author: Don Law
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: augeas
* Target version: 
* Affected Puppet version: 2.6.18
* Keywords: numeric comparitor onlyif
* Branch: 

The onlyif get comparitor always does string comparison.  This is fine until 
you try < or > (less than/greater than).  Many configuration parameters are 
numeric and should be compared as such when they are.

For an example use case, imagine a resource that enforces that the maximum 
password expiration must be less than 90 days.  If someone configures their 
system to use less than 90, no problem, but if it is configured for more than 
90, we need to set it to 90:

augeas {'testcase' :
  incl => '/home/dlaw/augeas/login.defs',
  lens => 'Login_defs.lns',
  context => '/files/home/dlaw/augeas/login.defs',
  onlyif => 'get PASS_MAX_DAYS > 90',
  changes => 'set PASS_MAX_DAYS 90',
}

The problem is if the following line appears in login.defs:

PASS_MAX_DAYS   120

the string comparision will show that 120 < 90, and the onlyif will not be true.

The following patch is a proposed fix for the problem:

--- OLD/site_ruby/1.8/puppet/provider/augeas/augeas.rb  2013-09-19 
14:09:52.0 -0400
+++ NEW/site_ruby/1.8/puppet/provider/augeas/augeas.rb  2013-09-19 
16:23:48.0 -0400
@@ -164,6 +164,10 @@
 end
   end
 
+  def is_numeric?(s)
+s.to_s.match(/\A[+-]?\d+?(\.\d+)?\Z/) == nil ? false : true
+  end
+
   # Used by the need_to_run? method to process get filters. Returns
   # true if there is a match, false if otherwise
   # Assumes a syntax of get /files/path [COMPARATOR] value
@@ -179,10 +183,14 @@
 
 #check the value in augeas
 result = @aug.get(path) || ''
-case comparator
-when "!="
+
+if comparator == "<" and is_numeric?(result) and is_numeric?(arg) 
+  return_value = result.to_s.to_f < arg.to_s.to_f
+elsif comparator == ">" and is_numeric?(result) and is_numeric?(arg) 
+  return_value = result.to_s.to_f > arg.to_s.to_f
+elsif comparator == "!="
   return_value = (result != arg)
-when "=~"
+elsif comparator == "=~"
   regex = Regexp.new(arg)
   return_value = (result =~ regex)
 else



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #11912] (Closed) Ruby DSL should be able to use defined resources

2013-09-19 Thread tickets

Issue #11912 has been updated by eric sorenson.

Status changed from Accepted to Closed
Assignee set to eric sorenson

Ruby dsl is deprecated and removed; won't fix this.


Bug #11912: Ruby DSL should be able to use defined resources
https://projects.puppetlabs.com/issues/11912#change-97761

* Author: Hunter Haugen
* Status: Closed
* Priority: Normal
* Assignee: eric sorenson
* Category: language
* Target version: 3.x
* Affected Puppet version: 
* Keywords: rubydsl, ruby, dsl, define
* Branch: 

Currently there is no way to use defined resources in puppet ruby dsl. At all.

Given a module called `test` with two defined resources:

1st: `test/manifests/def.pp`

define test::def {
  notify { 'test':
message => "Some test def for $name",
  }
}

2nd: `test/manifests/ruby_def.rb`

define 'test::ruby_def' do
  notify 'ruby test',
:message => "Some ruby test def for $name"
end

I can use both of these from a normal puppet manifest just fine:

`test/manifests/include.pp`

class test::include {
  test::def { 'my title1': }
  test::ruby_def { 'my ruby title1': }
}


THE BUG: The following example does not work. Puppet Ruby DSL cannot use either 
ruby defines or puppet defines with `create_resource`, and there are no other 
alternatives to use them. So defined resources are not possible to use in the 
puppet ruby dsl afaict:

`test/manifests/ruby_include.pp`

hostclass 'test::ruby_include' do
  create_resource 'test::def', 'my title'
  create_resource 'test::ruby_def', 'my ruby title'
end

The errors given:

Cannot find definition Test::Def on node training.puppetlabs.lan
Cannot find definition Test::Ruby_def on node training.puppetlabs.lan


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #21109] Puppet on windows sometimes crashes

2013-09-19 Thread tickets

Issue #21109 has been updated by Jose Cambronero.


Like Rob mentioned, I'm having the same issue. Except that the DLLs are 
different: msvcrt-ruby18.dll and ADVAPI32.DLL
The windows agents are crashing intermittently and we have puppet version 3.0.x 
installed.

Log Name:  Application
Source:Application Error
Date:  9/3/2013 9:50:59 AM
Event ID:  1000
Task Category: (100)
Level: Error
Keywords:  Classic
User:  N/A
Computer:  
Description:
Faulting application name: ruby.exe, version: 1.8.7.370, time stamp: 0x4fede15f
Faulting module name: msvcrt-ruby18.dll, version: 1.8.7.370, time stamp: 
0x4feddff4
Exception code: 0x4015
Fault offset: 0x00013152
Faulting process id: 0x938
Faulting application start time: 0x01cea8c5ae246efa
Faulting application path: C:\Program Files (x86)\Puppet 
Labs\Puppet\sys\ruby\bin\ruby.exe
Faulting module path: C:\Program Files (x86)\Puppet 
Labs\Puppet\sys\ruby\bin\msvcrt-ruby18.dll


Log Name:  Application
Source:Application Error
Date:  9/3/2013 9:51:00 AM
Event ID:  1000
Task Category: (100)
Level: Error
Keywords:  Classic
User:  N/A
Computer:  
Description:
Faulting application name: ruby.exe, version: 1.8.7.370, time stamp: 0x4fede15f
Faulting module name: ADVAPI32.DLL, version: 6.1.7601.17514, time stamp: 
0x4ce7b706
Exception code: 0xc005
Fault offset: 0x000149e5
Faulting process id: 0x938
Faulting application start time: 0x01cea8c5ae246efa
Faulting application path: C:\Program Files (x86)\Puppet 
Labs\Puppet\sys\ruby\bin\ruby.exe
Faulting module path: C:\Windows\syswow64\ADVAPI32.DLL


Bug #21109: Puppet on windows sometimes crashes
https://projects.puppetlabs.com/issues/21109#change-97764

* Author: Josh Cooper
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.1.1
* Keywords: windows
* Branch: 

>From Michael O'Dea:

I noticed that a number of my Windows hosts had stopped dialing in, and upon 
closer inspection I found that Puppet was crashing in Ruby and wevtapi.dll.  I 
can't find any reference to this in the issue tracker, although I've got over a 
dozen occurrences in my environment, all with the same descriptions as below.  
I checked to see if the times were similar, in case the server presented some 
bad data to cause the issue, but the crashes occurred at all different times 
and days.  

My question is, has anyone else seen this?  Is this a known issue?  If it is 
fixed in 3.2.1, can I install 3.2.1 clients against a 3.1.x server?  In the 
meantime, I will be rolling back to an older 2.7.x version that we'd run for 
some time without issue.  

Thanks in advance.  Fault details below.  


Faulting application name: ruby.exe, version: 1.8.7.371, time stamp: 0x5083a46c
Faulting module name: wevtapi.DLL, version: 6.1.7600.16385, time stamp: 
0x4a5bdb2d
Exception code: 0xc005
Fault offset: 0x1360
Faulting process id: 0xa48
Faulting application start time: 0x01ce5e0840c39580
Faulting application path: C:\Program Files (x86)\Puppet 
Labs\Puppet\sys\ruby\bin\ruby.exe
Faulting module path: C:\Windows\system32\wevtapi.DLL
Report Id: 487d9720-c9fc-11e2-8a25-0a252c8f038f



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22557] Regression on arrays and puppet resources using the name attribute

2013-09-19 Thread tickets

Issue #22557 has been updated by Josh Cooper.


I can reproduce on ruby 1.8.7:


root@puppetmaster:~# puppet apply -e "package { 'nrpe': name => 
['nagios-plugins', 'nagios-nrpe-server'], ensure=> present }"
Notice: Compiled catalog for puppetmaster.solar.lan in environment production 
in 0.14 seconds
Warning: Failed to match dpkg-query line "No packages found matching 
nagios-plugins.\n"
Notice: /Stage[main]//Package[nrpe]/ensure: ensure changed 'purged' to 'present'
Notice: Finished catalog run in 48.18 seconds

root@puppetmaster:~# puppet apply -e "package { 'nrpe': name => 
['nagios-plugins', 'nagios-nrpe-server'], ensure=> present }"
Notice: Compiled catalog for puppetmaster.solar.lan in environment production 
in 0.11 seconds
Notice: /Stage[main]//Package[nrpe]/ensure: ensure changed 'purged' to 'present'
Notice: Finished catalog run in 0.40 seconds

root@puppetmaster:~# puppet apply -e "package { ['nagios-plugins', 
'nagios-nrpe-server']: ensure=> present }"
Notice: Compiled catalog for puppetmaster.solar.lan in environment production 
in 0.10 seconds
Notice: Finished catalog run in 0.09 seconds

root@puppetmaster:~# dpkg -l | grep nagios
ii  nagios-nrpe-server   2.12-4
Nagios Remote Plugin Executor Server
ii  nagios-plugins   1.4.15-3squeeze1  
Plugins for the nagios network monitoring and management system
ii  nagios-plugins-basic 1.4.15-3squeeze1  
Plugins for the nagios network monitoring and management system
ii  nagios-plugins-standard  1.4.15-3squeeze1  
Plugins for the nagios network monitoring and management system

root@puppetmaster:~# puppet --version
3.3.0

root@puppetmaster:~# ruby --version
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]




Bug #22557: Regression on arrays and puppet resources using the name attribute
https://projects.puppetlabs.com/issues/22557#change-97756

* Author: William Van Hevelingen
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Upgraded to Puppet 3.3.0 and started getting these errors.

Reporting broken for arrays on puppet resources using the name attribute.


# puppet apply -e "package { 'nrpe': name => ['nagios-plugins', 
'nagios-nrpe-server'], ensure=>present } "
Notice: Compiled catalog for foo.lan in environment production in 1.72 seconds
Notice: /Stage[main]//Package[nrpe]/ensure: ensure changed 'purged' to 'present'



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22576] Puppet 3.3 changes behaviour for file { replace => false } when link is on fs

2013-09-19 Thread tickets

Issue #22576 has been updated by eric sorenson.


eric sorenson wrote:
> I think this is still doing what you expect, it's just logging a message 
> where before there was no message. See the linked bug #6808 -- many users 
> found this behaviour surprising so the warning is just saying what's going on.

The question is, I guess, whether you're seeing the actual underlying behaviour 
change or whether it's just that you are unused to seeing the new message.


Bug #22576: Puppet 3.3 changes behaviour for file { replace => false } when 
link is on fs
https://projects.puppetlabs.com/issues/22576#change-97760

* Author: Alex Jurkiewicz
* Status: Needs More Information
* Priority: Normal
* Assignee: Alex Jurkiewicz
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Hi,
Given this config in my manifest:

file { '/foo':
  ensure => present,
  content => "\n",
  replace => false,
}

In Puppet <3.3 it would succeed silently when /foo was a symlink. Now it gives 
the following error:

Warning: /Stage[main]/Soe/File[/foo]: Ensure set to :present but file type 
is link so no content will be synced

Our manifest relies on the behaviour where "replace => false" ignores the file 
if it is a symlink, can this be made possible again please?


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22576] Puppet 3.3 changes behaviour for file { replace => false } when link is on fs

2013-09-19 Thread tickets

Issue #22576 has been updated by eric sorenson.


I’ve put this ticket’s status into “Needs more Information” and assigned it to 
you. Please either (a) update it with the information I’ve requested and 
re-assign it to me if you need more help, or (b) change the status to “Closed” 
if you were able to resolve the issue on your own.


Bug #22576: Puppet 3.3 changes behaviour for file { replace => false } when 
link is on fs
https://projects.puppetlabs.com/issues/22576#change-97759

* Author: Alex Jurkiewicz
* Status: Needs More Information
* Priority: Normal
* Assignee: Alex Jurkiewicz
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Hi,
Given this config in my manifest:

file { '/foo':
  ensure => present,
  content => "\n",
  replace => false,
}

In Puppet <3.3 it would succeed silently when /foo was a symlink. Now it gives 
the following error:

Warning: /Stage[main]/Soe/File[/foo]: Ensure set to :present but file type 
is link so no content will be synced

Our manifest relies on the behaviour where "replace => false" ignores the file 
if it is a symlink, can this be made possible again please?


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22576] (Needs More Information) Puppet 3.3 changes behaviour for file { replace => false } when link is on fs

2013-09-19 Thread tickets

Issue #22576 has been updated by eric sorenson.

Status changed from Investigating to Needs More Information
Assignee set to Alex Jurkiewicz

I think this is still doing what you expect, it's just logging a message where 
before there was no message. See the linked bug #6808 -- many users found this 
behaviour surprising so the warning is just saying what's going on.


Bug #22576: Puppet 3.3 changes behaviour for file { replace => false } when 
link is on fs
https://projects.puppetlabs.com/issues/22576#change-97758

* Author: Alex Jurkiewicz
* Status: Needs More Information
* Priority: Normal
* Assignee: Alex Jurkiewicz
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Hi,
Given this config in my manifest:

file { '/foo':
  ensure => present,
  content => "\n",
  replace => false,
}

In Puppet <3.3 it would succeed silently when /foo was a symlink. Now it gives 
the following error:

Warning: /Stage[main]/Soe/File[/foo]: Ensure set to :present but file type 
is link so no content will be synced

Our manifest relies on the behaviour where "replace => false" ignores the file 
if it is a symlink, can this be made possible again please?


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22576] (Investigating) Puppet 3.3 changes behaviour for file { replace => false } when link is on fs

2013-09-19 Thread tickets

Issue #22576 has been updated by Josh Cooper.

Status changed from Unreviewed to Investigating

Thr behavior change occurred in 
[501f8f1f](https://github.com/puppetlabs/puppet/commit/501f8f1fc10f30c0a99a34e1c8856fa22db02a87)
 for #6808.


Bug #22576: Puppet 3.3 changes behaviour for file { replace => false } when 
link is on fs
https://projects.puppetlabs.com/issues/22576#change-97755

* Author: Alex Jurkiewicz
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Hi,
Given this config in my manifest:

file { '/foo':
  ensure => present,
  content => "\n",
  replace => false,
}

In Puppet <3.3 it would succeed silently when /foo was a symlink. Now it gives 
the following error:

Warning: /Stage[main]/Soe/File[/foo]: Ensure set to :present but file type 
is link so no content will be synced

Our manifest relies on the behaviour where "replace => false" ignores the file 
if it is a symlink, can this be made possible again please?


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #2105] Order matters with tagged function

2013-09-19 Thread tickets

Issue #2105 has been updated by Josh Cooper.

Affected Puppet version changed from 3.3.0 to 0.24.8

Hi Samuli, we try to keep the affected puppet version as the earliest known 
version the issue exists, so resetting back to 0.24.8


Bug #2105: Order matters with tagged function
https://projects.puppetlabs.com/issues/2105#change-97753

* Author: Lawrence Ludwig
* Status: Needs Decision
* Priority: Normal
* Assignee: Nick Fagerlund
* Category: documentation
* Target version: 
* Affected Puppet version: 0.24.8
* Keywords: 
* Branch: 

It should be noted in the documentation of the limits when using the 'tagged' 
function ordering of classes via 'include' matters.  Ie this code.

code:

class a {
notify {"class a": }
if tagged("b") {
notify {"found class b": }
}
}

class b {
notify {"class b": }
}

class test {
notify {"class test": }
include a
include b
}



test output:

[root@bast ~]# puppet -e "include test" test.pp  --verbose --logdest=console 
--debug
debug: importing '/home/larry/test.pp'
info: Autoloaded module test
debug: Creating default schedules
debug: //test/a/Notify[class a]: Changing message
debug: //test/a/Notify[class a]: 1 change(s)
notice: class a
notice: //test/a/Notify[class a]/message: defined 'message' as 'class a'
debug: //test/Notify[class test]: Changing message
debug: //test/Notify[class test]: 1 change(s)
notice: class test
notice: //test/Notify[class test]/message: defined 'message' as 'class test'
debug: //test/b/Notify[class b]: Changing message
debug: //test/b/Notify[class b]: 1 change(s)
notice: class b
notice: //test/b/Notify[class b]/message: defined 'message' as 'class b'
debug: Finishing transaction 70131190151540 with 3 changes



will only output "found class b" when the order of includes is reversed.







-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Feature #4424] (Merged - Pending Release) umask parameter for exec

2013-09-19 Thread tickets

Issue #4424 has been updated by Adrien Thebo.

Status changed from Accepted to Merged - Pending Release
Assignee deleted (Charlie Sharpsteen)
Target version set to 3.4.0
Branch set to https://github.com/puppetlabs/puppet/pull/1899

Merged into master in 092f9df; this should be released in 3.4.0.


Feature #4424: umask parameter for exec
https://projects.puppetlabs.com/issues/4424#change-97748

* Author: martin krafft
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: exec
* Target version: 3.4.0
* Affected Puppet version: 0.25.5
* Keywords: exec umask customer
* Branch: https://github.com/puppetlabs/puppet/pull/1899

It would be grand if the exec type grew a umask parameter.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22608] (In Topic Branch Pending Review) filebucket (backup) does not work with 3.3.0 master and older clients

2013-09-19 Thread tickets

Issue #22608 has been updated by Josh Cooper.

Status changed from Accepted to In Topic Branch Pending Review
Branch set to https://github.com/puppetlabs/puppet/pull/1919


Bug #22608: filebucket (backup) does not work with 3.3.0 master and older 
clients
https://projects.puppetlabs.com/issues/22608#change-97752

* Author: Bernhard Schmidt
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.3.1
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/1919

After upgrading the master to 3.3.0 backing up changed files from older clients 
does not work anymore.

2013-09-18 16:31:06 + /File[/etc/ferm/ferm.d/20-funcs.ferm]/content 
(err): change from {md5}66618d21aa5f26e836a171cc07c038a4 to 
{md5}ec8100f38c6f882eff001a3e6b67385c failed: Could not back up 
/etc/ferm/ferm.d/20-funcs.ferm: Error 406 on SERVER: Not Acceptable: No 
supported formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)

Setting the report_serialization_format setting to yaml does not seem to help 
here.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Facter - Bug #21530] cfpropertylist .to_plist method doesn't output Apple standard XML format

2013-09-19 Thread tickets

Issue #21530 has been updated by Brian Warsing.


Christian,

If I understand correctly I should be able to do this...

https://github.com/ckruse/CFPropertyList/issues/22

No?

Christian Kruse wrote:
> Brian Warsing wrote:
> > The only question is, will it break something else?
> 
> It wont break something, but it will only work on machines where neither 
> libxml nor nokogiri is installed.
> 
> I think a better solution would be a default flag in CFPropertyList. I  
> implemented it this way:
> 
> https://github.com/ckruse/CFPropertyList/commit/6e41a0cb16188cef368aeb80e42e054e18008b51
> 
> You only need to set plist.formatted = true and the plist is formatted by 
> default
> 
> Can you check if it works for you? If yes, I release a new version.




Bug #21530: cfpropertylist .to_plist method doesn't output Apple standard XML 
format
https://projects.puppetlabs.com/issues/21530#change-97746

* Author: Clay Caviness
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected Facter version: 

The output when using FORMAT_XML isn't in Apple style, with tab indention, but 
is instead all on one line. While this is valid XML, it's not pretty. We 
generally like to write XML plists and not binary, as they're simpler to read 
without extra tools.


$ ruby -r facter -r facter/util/plist -e "p = {'foo'=>'bar', 
'baz'=>[1,2,3]}.to_plist(); puts p"

;


  baz
  
1
2
3
  
  foo
  bar


$ facter --version
1.6.2
$ sudo pkgutil --forget com.reductivelabs.facter
Forgot package 'com.reductivelabs.facter' on '/'.
$ sudo installer -target / -pkg /Volumes/facter-1.7.1/facter-1.7.1.pkg
installer: Package name is facter-1.7.1
installer: Installing at base path /
installer: The install was successful.
$ ruby -r facter -r facter/util/cfpropertylist -e "p = {'foo'=>'bar', 
'baz'=>[1,2,3]}.to_plist({:plist_format=>2}); puts p"

;
baz123foobar
$ facter --version
1.7.1



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Feature #3946] (Merged - Pending Release) providers should have a finalize class method

2013-09-19 Thread tickets

Issue #3946 has been updated by Adrien Thebo.

Status changed from In Topic Branch Pending Review to Merged - Pending Release
Target version set to 3.4.0

Merged into master in af5fb2f; this should be released in 3.4.0. With respect 
to the method name chosen, see 
https://groups.google.com/forum/#!topic/puppet-dev/2blbxCo5pzg.


Feature #3946: providers should have a finalize class method
https://projects.puppetlabs.com/issues/3946#change-97749

* Author: Dan Bode
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: plumbing
* Target version: 3.4.0
* Affected Puppet version: 3.2.3
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/1851

For providers that serve as a proxy, it makes sense to open all connections and 
set up all dependencies in the self.prefetch method. This requires an 
additional method that is called once per class instance where these 
connections can be closed. Something like self.finalize (borrowing from Java 
terminology)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22608] (Needs More Information) filebucket (backup) does not work with 3.3.0 master and older clients

2013-09-19 Thread tickets

Issue #22608 has been updated by Josh Cooper.

Status changed from Unreviewed to Needs More Information

Hi Bernhard, what are the client's puppet and ruby versions?


Bug #22608: filebucket (backup) does not work with 3.3.0 master and older 
clients
https://projects.puppetlabs.com/issues/22608#change-97737

* Author: Bernhard Schmidt
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

After upgrading the master to 3.3.0 backing up changed files from older clients 
does not work anymore.

2013-09-18 16:31:06 + /File[/etc/ferm/ferm.d/20-funcs.ferm]/content 
(err): change from {md5}66618d21aa5f26e836a171cc07c038a4 to 
{md5}ec8100f38c6f882eff001a3e6b67385c failed: Could not back up 
/etc/ferm/ferm.d/20-funcs.ferm: Error 406 on SERVER: Not Acceptable: No 
supported formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)

Setting the report_serialization_format setting to yaml does not seem to help 
here.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22608] (Accepted) filebucket (backup) does not work with 3.3.0 master and older clients

2013-09-19 Thread tickets

Issue #22608 has been updated by Josh Cooper.

Status changed from Needs More Information to Accepted
Target version set to 3.3.1

With 3.3.0 master (passenger) I can reproduce with 2.7.18, 3.1.1, 3.2.4 agents 


root@deb-agent:~# puppet agent -t --server puppetmaster.solar.lan
Error: Could not back up /tmp/foo/foo.txt: Error 406 on SERVER: Not Acceptable: 
No supported formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)
Error: Could not back up /tmp/foo/foo.txt: Error 406 on SERVER: Not Acceptable: 
No supported formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)
Error: /File[/tmp/foo/foo.txt]/ensure: change from file to absent failed: Could 
not back up /tmp/foo/foo.txt: Error 406 on SERVER: Not Acceptable: No supported 
formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)
...
root@deb-agent:~# ruby --version
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
root@deb-agent:~# puppet --version
3.2.4



Bug #22608: filebucket (backup) does not work with 3.3.0 master and older 
clients
https://projects.puppetlabs.com/issues/22608#change-97740

* Author: Bernhard Schmidt
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.3.1
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

After upgrading the master to 3.3.0 backing up changed files from older clients 
does not work anymore.

2013-09-18 16:31:06 + /File[/etc/ferm/ferm.d/20-funcs.ferm]/content 
(err): change from {md5}66618d21aa5f26e836a171cc07c038a4 to 
{md5}ec8100f38c6f882eff001a3e6b67385c failed: Could not back up 
/etc/ferm/ferm.d/20-funcs.ferm: Error 406 on SERVER: Not Acceptable: No 
supported formats are acceptable (Accept: pson, b64_zlib_yaml, yaml, raw)

Setting the report_serialization_format setting to yaml does not seem to help 
here.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22557] Regression on arrays and puppet resources using the name attribute

2013-09-19 Thread tickets

Issue #22557 has been updated by Josh Cooper.

Description updated


Bug #22557: Regression on arrays and puppet resources using the name attribute
https://projects.puppetlabs.com/issues/22557#change-97735

* Author: William Van Hevelingen
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

Upgraded to Puppet 3.3.0 and started getting these errors.

Reporting broken for arrays on puppet resources using the name attribute.


# puppet apply -e "package { 'nrpe': name => ['nagios-plugins', 
'nagios-nrpe-server'], ensure=>present } "
Notice: Compiled catalog for foo.lan in environment production in 1.72 seconds
Notice: /Stage[main]//Package[nrpe]/ensure: ensure changed 'purged' to 'present'



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #20865] (Now) consistent unexpected behavior when notifying exec ressources having "onlyif" parameter set

2013-09-19 Thread tickets

Issue #20865 has been updated by Josh Cooper.

Affected Puppet version changed from 3.3.0 to 3.1.1

Setting affected version back to when the problem first occurred, though I 
understand the problem is worse now in 3.3.0.


Bug #20865: (Now) consistent unexpected behavior when notifying exec ressources 
having "onlyif" parameter set
https://projects.puppetlabs.com/issues/20865#change-97734

* Author: Christian Flamm
* Status: Accepted
* Priority: High
* Assignee: 
* Category: transactions
* Target version: 3.x
* Affected Puppet version: 3.1.1
* Keywords: exec onlyif notify
* Branch: 

Please have a look at this simplified example.

class runtimevariation {
  # dummy file ressources that should represent
  # some real software deployment
  file { '/tmp/software-v1': ensure => present, }

  file { '/tmp/software-v2': ensure => present, }

  file { '/tmp/software-v3': ensure => present, }

  # indicating current version in use
  file { '/tmp/current':
ensure  => link,
target  => '/tmp/software-v2',
require => File['/tmp/software-v2'],
notify  => Exec['software.restart'],
  }

  # whenever link target changes I want to run this - but
  # only if the file exists and is executable
  exec { 'software.restart':
refreshonly => true,
command => '/tmp/restart/software',
onlyif  => '/usr/bin/[ -x /tmp/restart/software ]'
  }
}

On the configured machine:

# ll /tmp/
total 0
lrwxrwxrwx 1 root root 16 May 23 08:41 current -> /tmp/software-v2
-rw-r--r-- 1 root root  0 May 23 08:40 software-v1
-rw-r--r-- 1 root root  0 May 23 08:41 software-v2
-rw-r--r-- 1 root root  0 May 23 08:41 software-v3

There are a couple of different '/tmp/software-v*' file resources. There's a 
'/tmp/current' link pointing to either one of them. Whenever something about 
the link file resource (e.g. target) changes I want to notify the 
'software.restart' exec resource to run a command but only if a matching 
executable exists.

**My assumption was**: if nothing about the whole catalog/class changes 
(particularly the '/tmp/current' link) then the exec resource would never get 
notified and so neither the onlyif check nor the command would be run.

**But: the onlyif check does sometimes get run**. I just don't understand when 
and why. During the following puppet agent runs nothing about the node's 
catalog (only containing class runtimevariation) changes.

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 Debug: Exec[software.restart](provider=posix): Executing check '/usr/bin/[ 
-x /tmp/restart/software ]'
 Debug: Executing '/usr/bin/[ -x /tmp/restart/software ]'

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 nothing!

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 Debug: Exec[software.restart](provider=posix): Executing check '/usr/bin/[ 
-x /tmp/restart/software ]'
 Debug: Executing '/usr/bin/[ -x /tmp/restart/software ]'

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 nothing!

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 nothing!

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 Debug: Exec[software.restart](provider=posix): Executing check '/usr/bin/[ 
-x /tmp/restart/software ]'
 Debug: Executing '/usr/bin/[ -x /tmp/restart/software ]'

# puppet agent --no-daemonize --debug --onetime | grep "/usr/bin/\[ -x "
 nothing!

Sometimes the onlyif check does get executed... sometimes not.

This becomes more interessting if you have a bunch of such exec ressources with 
(more) expensive onlyif checks. In our setup this makes a difference of 15-20s 
vs. 30-35s per catalog run.




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22586] (Needs More Information) Link does not work: http://links.puppetlabs.com/deprecate_yaml_on_network

2013-09-19 Thread tickets

Issue #22586 has been updated by Josh Cooper.

Status changed from Unreviewed to Needs More Information

Hi James, the link is a public and redirects to 
. It works for me without needing 
to be logged into redmine. What happens when you select the link?


Bug #22586: Link does not work: 
http://links.puppetlabs.com/deprecate_yaml_on_network
https://projects.puppetlabs.com/issues/22586#change-97733

* Author: James Patterson
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: 
* Branch: 

The link http://links.puppetlabs.com/deprecate_yaml_on_network is not 
accessible. It requires a login.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22613] (Duplicate) puppet agent installer 3.2.4 and 3.3.0 on windows xp (sp2 and sp3) german edition gives “Service 'Puppet Agent' (puppet) failed to start. Verify that you have suffici

2013-09-19 Thread tickets

Issue #22613 has been updated by Josh Cooper.

Status changed from Unreviewed to Duplicate


Bug #22613: puppet agent installer 3.2.4 and 3.3.0 on windows xp (sp2 and sp3) 
german edition gives “Service 'Puppet Agent' (puppet) failed to start. Verify 
that you have sufficient privileges to start system services."
https://projects.puppetlabs.com/issues/22613#change-97730

* Author: Claudiu Vasadi
* Status: Duplicate
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

I noticed this problem on Windows XP Professional SP2 and SP3 german edition 
only (VM and physical machine). Basically, the installation process goes all 
the way through and then it fails to start the service. Keeping an eye on 
"Services" I noticed the installer trying to restart the service 3 times and 
then giving up. The "Event Viewer" gives not much extra info.

Puppet agent for windows works fine on Windows XP SP2 and SP3 english edition.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22616] (Unreviewed) Cannot disable 'firstboot' service, but keeps 'stopping' it

2013-09-19 Thread tickets

Issue #22616 has been reported by Jasper Lievisse Adriaanse.


Bug #22616: Cannot disable 'firstboot' service, but keeps 'stopping' it
https://projects.puppetlabs.com/issues/22616

* Author: Jasper Lievisse Adriaanse
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: service
* Target version: 
* Affected Puppet version: 3.3.0
* Keywords: service
* Branch: 

On a Scientific Linux 6.4 installation I'm running into some odd problems with 
services. Namely that 'firstboot' is never really disabled, it stays on for 
runlevel 1 and everytime Puppet runs, it thinks it's stopping the service while 
it's not actually running. The same goes for 'udev-post' and 'blk-availability':



[root@VM /]# chkconfig --list | grep firstboot
firstboot   0:off   1:off   2:off   3:off   4:off   5:off   6:off
[root@VM /]#
[root@VM /]# puppet agent -t
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/virtual_guests_count.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pending_updates.rb
Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppi_projects.rb
Info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/iptables_persistent_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/virtual_guests.rb
Info: Loading facts in /var/lib/puppet/lib/facter/last_run.rb
Info: Caching catalog for VM.local
Info: Applying configuration version '1379489282'
Notice: /Stage[main]/Services::Disable/Service[firstboot]/ensure: ensure 
changed 'running' to 'stopped'
Notice: /Stage[main]/Services::Disable/Service[udev-post]/ensure: ensure 
changed 'running' to 'stopped'
Notice: /Stage[main]/Services::Disable/Service[blk-availability]/ensure: ensure 
changed 'running' to 'stopped'
Notice: Finished catalog run in 7.06 seconds
[root@VM /]#
[root@VM /]# chkconfig --list | grep firstboot
firstboot   0:off   1:off   2:off   3:off   4:off   5:off   6:off


[root@VM /]# service firstboot status
firstboot is not scheduled to run
[root@VM /]# service udev-post status
[root@VM /]# service blk-availability status
[root@VM /]#
[root@VM /]# puppet agent -t
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/virtual_guests_count.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pending_updates.rb
Info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppi_projects.rb
Info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb
Info: Loading facts in /var/lib/puppet/lib/facter/iptables_persistent_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb
Info: Loading facts in /var/lib/puppet/lib/facter/virtual_guests.rb
Info: Loading facts in /var/lib/puppet/lib/facter/last_run.rb
Info: Caching catalog for VM.local
Info: Applying configuration version '1379489282'
Notice: /Stage[main]/Services::Disable/Service[firstboot]/ensure: ensure 
changed 'running' to 'stopped'
Notice: /Stage[main]/Services::Disable/Service[udev-post]/ensure: ensure 
changed 'running' to 'stopped'
Notice: /Stage[main]/Services::Disable/Service[blk-availability]/ensure: ensure 
changed 'running' to 'stopped'
Notice: Finished catalog run in 7.50 seconds
[root@VM /]#
[root@VM /]# service firstboot status
firstboot is not scheduled to run
[root@VM /]# service udev-post status
[root@VM /]# service blk-availability status
[root@VM /]#




The Services::Disable module just uses create_resources() to create a Service 
resource so there is nothing there that could cause that behaviour.
Any idea what is going, are the actual init scripts to blame or is Puppet at 
fault?


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 optio

[Puppet - Bug #22615] (Unreviewed) Hiera ignores symbols in yaml files

2013-09-19 Thread tickets

Issue #22615 has been reported by Andrea Ieri.


Bug #22615: Hiera ignores symbols in yaml files
https://projects.puppetlabs.com/issues/22615

* Author: Andrea Ieri
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: hiera yaml symbol
* Branch: 

If a value in hiera is defined as '!ruby/symbol SymbolName' the lookup returns 
nil.
This is probably because parse_answer ignores symbols.


  # Parses a answer received from data files
  #
  # Ultimately it just pass the data through parse_string but
  # it makes some effort to handle arrays of strings as well
  def parse_answer(data, scope, extra_data={})
if data.is_a?(Numeric) or data.is_a?(TrueClass) or 
data.is_a?(FalseClass)
  return data
elsif data.is_a?(String)
  return parse_string(data, scope, extra_data)
elsif data.is_a?(Hash)
  answer = {}
  data.each_pair do |key, val|
interpolated_key = parse_string(key, scope, extra_data)
answer[interpolated_key] = parse_answer(val, scope, extra_data)
  end

  return answer
elsif data.is_a?(Array)
  answer = []
  data.each do |item|
answer << parse_answer(item, scope, extra_data)
  end

  return answer
end
  end


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22613] (Unreviewed) puppet agent installer 3.2.4 and 3.3.0 on windows xp (sp2 and sp3) german edition gives “Service 'Puppet Agent' (puppet) failed to start. Verify that you have suffic

2013-09-19 Thread tickets

Issue #22613 has been reported by Claudiu Vasadi.


Bug #22613: puppet agent installer 3.2.4 and 3.3.0 on windows xp (sp2 and sp3) 
german edition gives “Service 'Puppet Agent' (puppet) failed to start. Verify 
that you have sufficient privileges to start system services."
https://projects.puppetlabs.com/issues/22613

* Author: Claudiu Vasadi
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

I noticed this problem on Windows XP Professional SP2 and SP3 german edition 
only (VM and physical machine). Basically, the installation process goes all 
the way through and then it fails to start the service. Keeping an eye on 
"Services" I noticed the installer trying to restart the service 3 times and 
then giving up. The "Event Viewer" gives not much extra info.

Puppet agent for windows works fine on Windows XP SP2 and SP3 english edition.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Puppet - Bug #22340] (Duplicate) puppet node deactivate fails with SSL error

2013-09-19 Thread tickets

Issue #22340 has been updated by Ken Barber.

Status changed from Unreviewed to Duplicate

This is a duplicate of #20838 so I'm going to close this.

Bruce, I've had trouble trying to replicate this one, and the last time it 
fixed itself it was random (ie. we didn't know why it fixed itself). Perhaps 
you'd prefer to jump onto IRC and talk about this, I'm on freenode, #puppet as 
@ken_barber. Otherwise it might take some backwards and forwards in a ticket or 
email, which can be super annoying for this kind of issue and not as productive 
- especially considering I have no clear answer for you.


Bug #22340: puppet node deactivate  fails with SSL error
https://projects.puppetlabs.com/issues/22340#change-97722

* Author: bruce lysik
* Status: Duplicate
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: puppetdb
* Branch: 

puppet master: RHEL 6u2 upgraded with most errata and puppet 3.2.3 packages.
puppetdb: RHEL 6u4, and puppetdb-1.4.0, jre1.7.0_13

-bash-4.1$ sudo puppet node deactivate 
Error: Failed to submit 'deactivate node' command for  to PuppetDB at 
:8081: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3 
read finished A
Error: Try 'puppet help node deactivate' for usage
-bash-4.1$ 

Other functionality of the puppetdb server is working fine.  



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.


[Facter - Bug #21604] Virtual fact is not working properly for VM

2013-09-19 Thread tickets

Issue #21604 has been updated by Josh Cooper.


It looks like Adrien merged this in 
[2d268ba](https://github.com/puppetlabs/facter/commit/2d268ba) into master, so 
this change will not be released until 2.0 or 1.8, whichever comes first.


Bug #21604: Virtual fact is not working properly for VM
https://projects.puppetlabs.com/issues/21604#change-97719

* Author: Lorenzo Cubero
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: virtual
* Target version: 1.7.4
* Keywords: windows
* Branch: https://github.com/puppetlabs/facter/pull/495
* Affected Facter version: 

Hi,

Facter says $virtual => physical for Windows Server 2008 R2 VM on Xen.

It also returns the hardware processor model.

The machine has puppet 3.2.2 installed.

Thks.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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/groups/opt_out.