[Puppet - Bug #15326] (Merged - Pending Release) Scheduled_task does not accept domain user accounts

2012-10-24 Thread tickets 

Issue #15326 has been updated by Andrew  Parker.

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

Merged into 2.7.x in 


Bug #15326: Scheduled_task does not accept domain user accounts
https://projects.puppetlabs.com/issues/15326#change-74895

Author: Josh Cooper
Status: Merged - Pending Release
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.20
Affected Puppet version: 2.7.17
Keywords: windows scheduled_task domain user
Branch: https://github.com/puppetlabs/puppet/pull/1225


>From 
>

The `scheduled_task` resource type does not accept domain user accounts, though 
it should.


scheduled_task { 'test':
  ensure  => present,
  enabled => true,
  command => 'C:\test\test.bat',
  working_dir => 'C:\test',
  user=> 'DOMAIN\oper',
  password=> 'x',
  trigger => {
schedule => daily,
start_date   => '2012-06-26', # Defaults to 'today'
start_time   => '09:05',  # Must be specified
  }
}


The issue is that the logic for validating user/group accounts in 
`Puppet::Util::ADSI#sid_for_account` restricts the WMI query to local accounts. 
This is also an issue for files, e.g. setting the file owner to a domain user.

We do need to be careful about WMI queries that can return a lot of data, e.g. 
get all users in the Administrators group. But I don't think that is a concern 
with `sid_for_account` method, since we're just looking up the SID for a 
particular user.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16581] (Merged - Pending Release) Windows file permission management very slow

2012-10-24 Thread tickets 

Issue #16581 has been updated by Andrew  Parker.

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

Merged into 2.7.x in 


Bug #16581: Windows file permission management very slow
https://projects.puppetlabs.com/issues/16581#change-74894

Author: David Carr
Status: Merged - Pending Release
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.20
Affected Puppet version: 2.7.6
Keywords: windows file permissions user group sid slow performance
Branch: https://github.com/puppetlabs/puppet/pull/1225


I'm trying to write some Puppet manifests that support both Darwin and Windows. 
 So far, it's been going pretty well, but I noticed that my manifests were 
running much more slowly on Windows.  I believe that the majority of the 
slow-down is caused by File resources with owner/group/mode specified.  I'm 
able to reproduce a substantial performance difference between a manifest to 
create a single empty directory with/without permissions specified.  Manifests 
and output from "puppet apply --debug --verbose --no-daemonize --summarize 
--color=false --onetime MANIFEST" attached.  The machine I'm running these on 
is a Dell Latitude E6500 running Windows 7 64-bit with Puppet 3.0.0-rc7 
installed.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #9237] (Unreviewed) Failed refresh events do not get logged, or reported as errors.

2012-10-24 Thread tickets 

Issue #9237 has been updated by Ben Hughes.

Status changed from Investigating to Unreviewed
Assignee deleted (Ben Hughes)



Bug #9237: Failed refresh events do not get logged, or reported as errors.
https://projects.puppetlabs.com/issues/9237#change-74893

Author: Tim Alexander
Status: Unreviewed
Priority: High
Assignee: 
Category: metaparameters
Target version: 
Affected Puppet version: 2.7.1
Keywords: 
Branch: 


Similar to Bug #5670 and Bug #6922 (especially Bug #6922)

refresh calls on all types are not registering a failure. If an exec does not 
have a refresh defined, this does work properly (see Bug #6922).

Taken directly from the cheatsheet PDF, below is one example. An easily 
executable example is included later. The result of this bug is if sshd_config 
(below) is changed and causes Service['sshd'] to fail restart (returning other 
than return code 0), the failure won't be reported or even visible until the 
next puppet run that checks to make sure the service is running (and when it 
sees the service is stopped, it attempts to start it). Depending on your 
schedule/configuration this could be quite some time.


package { 'openssh-server':
ensure => installed,
}

file { '/etc/ssh/sshd_config':
source  => 'puppet:///modules/sshd/sshd_config',
owner   => 'root',
group   => 'root',
mode=> '640',
notify  => Service['sshd'], # sshd will restart whenever you edit this file.
require => Package['openssh-server'],
}

service { 'sshd':
ensure => running,
enable => true,
hasstatus => true,
hasrestart => true,
}


Here's an example using only exec statements (keeps it pretty self contained):


root@puppettest:/etc/puppet/manifests# cat test.pp 
exec { 'first':
command => '/bin/echo first',
refreshonly => true,
refresh => '/bin/false',
}

exec { 'second':
command => '/bin/echo second',
notify => Exec['first'],
}



root@puppettest:/etc/puppet/manifests# puppet apply test.pp --verbose --debug 
--trace
debug: Creating default schedules
debug: Failed to load library 'selinux' for feature 'selinux'

[SNIP]

debug: Finishing transaction 70246236951700
debug: Loaded state in 0.01 seconds
debug: Loaded state in 0.01 seconds
info: Applying configuration version '1314637523'
debug: /Stage[main]//Exec[second]/notify: subscribes to Exec[first]
debug: /Schedule[never]: Skipping device resources because running on a host
debug: /Schedule[daily]: Skipping device resources because running on a host
debug: /Schedule[monthly]: Skipping device resources because running on a host
debug: /Schedule[puppet]: Skipping device resources because running on a host
debug: /Schedule[hourly]: Skipping device resources because running on a host
debug: /Schedule[weekly]: Skipping device resources because running on a host
debug: Exec[second](provider=posix): Executing '/bin/echo second'
debug: Executing '/bin/echo second'
notice: /Stage[main]//Exec[second]/returns: executed successfully
debug: /Stage[main]//Exec[second]: The container Class[Main] will propagate my 
refresh event
info: /Stage[main]//Exec[second]: Scheduling refresh of Exec[first]
debug: Exec[first](provider=posix): Executing '/bin/false'
debug: Executing '/bin/false'
notice: /Stage[main]//Exec[first]: Triggered 'refresh' from 1 events
debug: /Stage[main]//Exec[first]: The container Class[Main] will propagate my 
refresh event
debug: Class[Main]: The container Stage[main] will propagate my refresh event
debug: Finishing transaction 70246236019520
debug: Storing state
debug: Stored state in 0.05 seconds
notice: Finished catalog run in 0.24 seconds
debug: Finishing transaction 70246235520580


NOTE: This fails properly if I set the initial command to '/bin/false' however, 
so it looks like there's a workaround for exec so long as no refresh is defined 
(not possible in some circumstances).


root@puppettest:/etc/puppet/manifests# cat test.pp
exec { 'first':
command => '/bin/false',
refreshonly => true,
#refresh => '/bin/false',
}   

exec { 'second':
command => '/bin/echo second',
notify => Exec['first'],
}   



root@puppettest:/etc/puppet/manifests# puppet apply test.pp --verbose --debug 
--trace
debug: Creating default schedules
debug: Failed to load library 'selinux' for feature 'selinux'

[SNIP]

debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: Finishing transaction 69917314836460
debug: Loaded state in 0.01 seconds
debug: Loaded state in 0.01 seconds
info: Applying configuration version '1314638357'
debug: /Stage[main]//Exec[second]/notify: subscribes to Exec[first]
debug: /Schedule[never]: Skipping device resources because running on a host
debug: /Schedule[daily]: Skipping device resources because running on a host
debug: /Schedule[monthly]: Skipping device resources because running on a host
debug: /Schedule[puppet]: Skipping device resources because running on a host
debug: /Schedule[hourly]: Skipping devic

[Puppet - Bug #17198] (Unreviewed) extlookup does not respect certname parameter

2012-10-24 Thread tickets 

Issue #17198 has been reported by Edwin Starkey.


Bug #17198: extlookup does not respect certname parameter
https://projects.puppetlabs.com/issues/17198

Author: Edwin Starkey
Status: Unreviewed
Priority: High
Assignee: 
Category: ext
Target version: 
Affected Puppet version: 2.7.9
Keywords: extlookup
Branch: 


To provide some background info, in my environment there are two teams - 
sysadmins and developers.

There many servers which end up having non-unique hostnames (examples: 
localhost, app1, node1, etc.).  From the developer's perspective, that's how it 
should be (they have additional justifications but I won't detail all of them 
here).  From the sysadmin's perspective, each server should somehow be uniquely 
identifiable in order to get the correct set of puppet modules applied to it.

I thought an easy solution would be to simply execute the puppet agent on each 
node using an additional parameter specifying the hostname (--fqdn or 
--certname).  That way, the developers could name the host whatever they 
wanted, and the correct puppet configuration would still be applied.

It does work, but with one caveat - extlookups continue to use the fqdn 
supplied by facter and not the one specified when executing puppet.  I 
confirmed this by attaching strace to the puppetmaster.

On the client:
[root@localhost ~]# puppet agent --certname foobar.mydomain.com --test 
--noop
info: Retrieving plugin
info: Caching catalog for foobar.mydomain.com
info: Applying configuration version '1351113554'
notice: Finished catalog run in 2.59 seconds
[root@localhost ~]#

It looks good so far - the server's actual hostname is localhost but by using 
the --certname parameter, puppet used the specified hostname.

On the puppetmaster:
[pid 19398] 
stat("/etc/puppet/environments/production/manifests/extdata/.csv", 
0x7fff53ff6ee0) = -1 ENOENT (No such file or directory)
[pid 19398] 
stat("/etc/puppet/environments/production/manifests/extdata/hostnames/localhost.mydomain.com.csv",
 0x7fff53ff4cc0) = -1 ENOENT (No such file or directory)
[pid 19398] 
stat("/etc/puppet/environments/production/manifests/extdata/hostgroups/localhost.csv",
 0x7fff53ff4cc0) = -1 ENOENT (No such file or directory)
[pid 19398] 
stat("/etc/puppet/environments/production/manifests/extdata/common.csv", 
{st_mode=S_IFREG|0644, st_size=1451, ...}) = 0
[pid 19398] 
open("/etc/puppet/environments/production/manifests/extdata/common.csv", 
O_RDONLY) = 17


As you can see, the puppetmaster is not using the specified certname when 
performing the extlookup.

I tried using both --certname and the --fqdn parameters, both returned the same 
result.  I think this is a bug.

Thanks. 


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #11042] (Merged - Pending Release) Inconsistent translation of group names to numbers when creating users in ldap

2012-10-24 Thread tickets 

Issue #11042 has been updated by Jeff McCune.

Status changed from Investigating to Merged - Pending Release
Assignee deleted (Jeff McCune)
Target version changed from 2.7.x to 2.7.20
Branch set to https://github.com/puppetlabs/puppet/pull/1234

# Merged into 2.7.x 3.0.x and master

As [c305a32](https://github.com/puppetlabs/puppet/commit/c305a32)


$ git branch --contains c305a32
  2.7.x
  3.0.x
* master


This fix will be released in Puppet 2.7.20, 3.0.2 and future major and minor 
releases.

Thank you for the contribution Neil.  If there's anything I can do to help with 
other problems you're facing please let me know.

-Jeff

Bug #11042: Inconsistent translation of group names to numbers when creating 
users in ldap
https://projects.puppetlabs.com/issues/11042#change-74877

Author: Neil Hemingway
Status: Merged - Pending Release
Priority: Normal
Assignee: 
Category: LDAP
Target version: 2.7.20
Affected Puppet version: 2.7.1
Keywords: LDAP provider user group
Branch: https://github.com/puppetlabs/puppet/pull/1234


Puppet::Provider::User::Ldap translates group names to numbers when modifying 
an existing user (using gid=), but not when creating a new one.

I believe this to be because gid= is not called when creating a new user due to 
the prefetch approach.

I have a couple of options for patches both of which seem to achieve the 
correct result, but (being new to the internals of puppet), I'm not sure 
whether I've "fixed" the problem in the best place, or whether there is 
somewhere more appropriate.

I've cloned the repo and will be pushing my patches to github under two 
different branches for you to compare/comment/rip to shreds/suggest 
improvements etc.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #11042] (Investigating) Inconsistent translation of group names to numbers when creating users in ldap

2012-10-24 Thread tickets 

Issue #11042 has been updated by Jeff McCune.

Status changed from Needs More Information to Investigating
Assignee changed from Neil Hemingway to Jeff McCune



Bug #11042: Inconsistent translation of group names to numbers when creating 
users in ldap
https://projects.puppetlabs.com/issues/11042#change-74872

Author: Neil Hemingway
Status: Investigating
Priority: Normal
Assignee: Jeff McCune
Category: LDAP
Target version: 2.7.x
Affected Puppet version: 2.7.1
Keywords: LDAP provider user group
Branch: 


Puppet::Provider::User::Ldap translates group names to numbers when modifying 
an existing user (using gid=), but not when creating a new one.

I believe this to be because gid= is not called when creating a new user due to 
the prefetch approach.

I have a couple of options for patches both of which seem to achieve the 
correct result, but (being new to the internals of puppet), I'm not sure 
whether I've "fixed" the problem in the best place, or whether there is 
somewhere more appropriate.

I've cloned the repo and will be pushing my patches to github under two 
different branches for you to compare/comment/rip to shreds/suggest 
improvements etc.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #11042] Inconsistent translation of group names to numbers when creating users in ldap

2012-10-24 Thread tickets 

Issue #11042 has been updated by Neil Hemingway.


Try [this pull request](https://github.com/puppetlabs/puppet/pull/1234)

Bug #11042: Inconsistent translation of group names to numbers when creating 
users in ldap
https://projects.puppetlabs.com/issues/11042#change-74869

Author: Neil Hemingway
Status: Needs More Information
Priority: Normal
Assignee: Neil Hemingway
Category: LDAP
Target version: 2.7.x
Affected Puppet version: 2.7.1
Keywords: LDAP provider user group
Branch: 


Puppet::Provider::User::Ldap translates group names to numbers when modifying 
an existing user (using gid=), but not when creating a new one.

I believe this to be because gid= is not called when creating a new user due to 
the prefetch approach.

I have a couple of options for patches both of which seem to achieve the 
correct result, but (being new to the internals of puppet), I'm not sure 
whether I've "fixed" the problem in the best place, or whether there is 
somewhere more appropriate.

I've cloned the repo and will be pushing my patches to github under two 
different branches for you to compare/comment/rip to shreds/suggest 
improvements etc.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #7680] Checksum missmatch when copying followed symlinks

2012-10-24 Thread tickets 

Issue #7680 has been updated by Oleg Atamanenko.


The bug is still exists in 3.0.1.

 

Bug #7680: Checksum missmatch when copying followed symlinks
https://projects.puppetlabs.com/issues/7680#change-74855

Author: Mikael Svantesson
Status: Accepted
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.6.8
Keywords: symlink file
Branch: 


When trying to copy a file (using a symlink), Puppet does not calculate the 
correct checksum for the temporary file.

This work in 2.6.7, I have not tried 2.7.x.

**Error:**
err: /Stage[pre]/Sudo/File[/etc/sudoers]/ensure: change from absent to 
present failed: Could not rename temporary file /etc/sudoers.puppettmp_4293 to 
/etc/sudoers:
File written to disk did not match checksum; discarding changes ( vs 
{md5}d41d8cd98f00b204e9800998ecf8427e) at 
/etc/puppet/modules/sudo/manifests/init.pp:12 at 
/etc/puppet/modules/sudo/manifests/init.pp:12

**Manifest:**
class sudo {
  package { 'sudo': ensure => installed }

  file { '/etc/sudoers':
ensure  => file,
source  => ["puppet:///modules/sudo/sudoers-${hostname}", 
'puppet:///modules/sudo/sudoers'],
links   => follow,
replace => true,
owner   => 'root',
group   => 'root',
mode=> '0440',
  }
}

**File structure:**
modules/sudo/files
|-- sudoers
|-- sudoers-host1
`-- sudoers-host2 -> sudoers-host1




-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet] 'Downloading Puppet' wiki page has been updated

2012-10-24 Thread tickets 

The 'Downloading Puppet' wiki page has been updated by Moses Mendoza.


Downloading Puppet:
https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet
View differences:
https://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet/diff/213

-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17192] (Unreviewed) Parsing issue with parameterized classes

2012-10-24 Thread tickets 

Issue #17192 has been reported by Tomas Doran.


Bug #17192: Parsing issue with parameterized classes
https://projects.puppetlabs.com/issues/17192

Author: Tomas Doran
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


If a class foo::bar uses a parameterized class bar, then this fails, as per 
this code:

class bar ($arg) {
  notify { $arg: }
}

class foo::bar {
  class {
'bar':
  arg => "baz";
  }
}

include foo::bar

Which errors with "Duplicate declaration: Class[Foo::Bar] is already declared; 
cannot redeclare at /home/tdoran/code/git/puppet/foo.pp:8 "

Which is incorrect, I'm not declaring a class, I'm trying to use/include a 
parameterized class.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Facter - Bug #17191] ipaddress error when no ips on any non local interfaces

2012-10-24 Thread tickets 

Issue #17191 has been updated by Garrett Honeycutt.




Bug #17191: ipaddress error when no ips on any  non local interfaces
https://projects.puppetlabs.com/issues/17191#change-74841

Author: Garrett Honeycutt
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Keywords: ipaddress
Branch: 
Affected Facter version: 


Facter throws an error when the only interface with an ipaddress is the local 
interface. It should not throw errors and should list all interfaces and their 
IP's in the ipaddress_ format.


# facter |grep ip
ipaddress => 172.19.131.116
ipaddress_en1 => 172.19.131.116
ipaddress_lo0 => 127.0.0.1

# ifconfig en1 down
# facter |grep ip
Could not retrieve ipaddress: No route to host - send(2)
Timed out seeking value for ipaddress
Could not retrieve ipaddress: No route to host - send(2)
Timed out seeking value for ipaddress
ipaddress_lo0 => 127.0.0.1

# facter facterversion
2.0.0



-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Facter - Bug #17191] (Unreviewed) ipaddress error when no ips on any non local interfaces

2012-10-24 Thread tickets 

Issue #17191 has been reported by Garrett Honeycutt.


Bug #17191: ipaddress error when no ips on any  non local interfaces
https://projects.puppetlabs.com/issues/17191

Author: Garrett Honeycutt
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Keywords: ipaddress
Branch: 
Affected Facter version: 


Facter throws an error when the only interface with an ipaddress is the local 
interface. It should not throw errors and should list all interfaces and their 
IP's in the ipaddress_ format.


# facter |grep ip
ipaddress => 172.19.131.116
ipaddress_en1 => 172.19.131.116
ipaddress_lo0 => 127.0.0.1

# ifconfig en1 down
# facter |grep ip
Could not retrieve ipaddress: No route to host - send(2)
Timed out seeking value for ipaddress
Could not retrieve ipaddress: No route to host - send(2)
Timed out seeking value for ipaddress
ipaddress_lo0 => 127.0.0.1

# facter facterversion
2.0.0



-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #16937] Improved Ruby DSL

2012-10-24 Thread tickets 

Issue #16937 has been updated by Nick Fagerlund.


I haven't had a chance to delve deeply yet, but I remember the new DSL 
including some non-standard use of words like "define." (Like using "define" to 
mean "declare a resource of a pre-existing native type.")

I'd like to make sure this gets looked at by UX and/or docs teams before the 
new DSL gets merged into consensus reality. If we send it live with language 
that conflicts with everything else, we're setting ourselves up for years of 
pain.

Feature #16937: Improved Ruby DSL
https://projects.puppetlabs.com/issues/16937#change-74840

Author: Andrew  Parker
Status: In Topic Branch Pending Review
Priority: High
Assignee: 
Category: language
Target version: 3.x
Affected Puppet version: 
Keywords: ruby, dsl, ruby dsl backlog
Branch: 


This is a tracking ticket for the Ruby DSL rewrite that was done as a Google 
Summer of Code project.

There original GSOC12 wording about this project was:

# Feature Parity for the Ruby DSL

## Project Title

Expand Features set for the Ruby DSL of Puppet

## Description/Benefits

The Ruby DSL for Puppet is missing a few features when compared to the native 
DSL. This project would align the Ruby DSL with the native DSL. Examples of 
missing features in the ruby DSL as it stands today:

 * no defined types
 * issues are symbols vs strings
 * parameterized classes validation
 * Composite namevars
 * inheritance/overrides


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #17190] (Unreviewed) detailed accounting/debugging of catalog compilation times

2012-10-24 Thread tickets 

Issue #17190 has been reported by Joshua Hoblitt.


Feature #17190: detailed accounting/debugging of catalog compilation times
https://projects.puppetlabs.com/issues/17190

Author: Joshua Hoblitt
Status: Unreviewed
Priority: Low
Assignee: 
Category: logging
Target version: 
Affected Puppet version: 2.7.19
Keywords: 
Branch: 


Recently, something has made my catalog compilation times jump up 
significantly.  All fingers are pointing towards this being the fault of new 
module(s) that are in use.  After some discussion on #puppet, it appears there 
is no intelligent way of diagnosing the code at fault except by removing 
modules one at a time from the manifests to see which is at fault.  So level of 
introspection on the catalog build process would be very helpful here.

It would be really useful to have a master side debugging mode that would dump 
detailed timing information on the catalog compilation process into the log.  
Perhaps something that could be enable for just a single agent names or a 
wildcard match.  I imagine tracing the timing to classes would be difficult but 
perhaps the amount of time spent on each resource would be possible to account 
for?  Ie, if I knew a ton of time was spent processing sshkey resources I'd 
could fairly quickly trace that back to the module 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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16667] Misleading error message "Not authorized to call find" after upgrading from 2.7 to 3.0

2012-10-24 Thread tickets 

Issue #16667 has been updated by Jeff McCune.


# Work around

The current work around to this issue is to remove the rules from 
`fileserver.conf` and instead implement authorization in `auth.conf`.

For example, if you had the following fileserver.conf in Puppet 2.7:


[files]
path/etc/puppet/files
allow   10.101.0.0/24
allow   10.103.0.0/24  


Then you can work around this issue in Puppet 3.0.0 and 3.0.1 with the 
following fileserver.conf and auth.conf respectively:


[files]
path/etc/puppet/files
# Access control is managed in auth.conf now
allow *



# This is an example auth.conf file, which implements the
# defaults used by the puppet master.
#
# The ACLs are evaluated in top-down order. More general
# stanzas should be towards the bottom of the file and more
# specific ones at the top, otherwise the general rules
# take precedence and later rules will not be evaluated.
#
# Supported syntax:
# Each stanza in auth.conf starts with a path to mach, followed
# by optional modifiers, and finally, a series of allow or deny
# directives. 
#
# Example Stanza
# -
# path /path/to/resource # simple prefix match
# # path ~ regex # alternately, regex match
# [environment envlist]
# [method methodlist]
# [auth[enthicated] {yes|no|on|off|any}]
# allow [host|backreference|*]
# deny [host|backreference|*]
# allow_ip [ip|cidr|ip_wildcard|*]
# deny_ip [ip|cidr|ip_wildcard|*]
#
# The path match can either be a simple prefix match or a regular 
# expression. `path /file` would match both `/file_metadata` and
# `/file_content`. Regex matches allow the use of backreferences
# in the allow/deny directives.
# 
# The regex syntax is the same as for Ruby regex, and captures backreferences
# for use in the `allow` and `deny` lines of that stanza
#
# Examples:
# path ~ ^/path/to/resource# equivalent to `path /path/to/resource`
# allow *
#
# path ~ ^/catalog/([^/]+)$# permit access only for the
# allow $1 # node whose cert matches the path
#
# environment:: restrict an ACL to a comma-separated list of environments
# method:: restrict an ACL to a comma-separated list of HTTP methods
# auth:: restrict an ACL to an authenticated or unauthenticated request
# the default when unspecified is to restrict the ACL to authenticated requests
# (ie exactly as if auth yes was present).
#

### Authenticated paths - these apply only when the client
### has a valid certificate and is thus authenticated

# allow nodes to retrieve their own catalog
path ~ ^/catalog/([^/]+)$
method find
allow $1

# allow nodes to retrieve their own node definition
path ~ ^/node/([^/]+)$
method find
allow $1

# allow all nodes to access the certificates services
path /certificate_revocation_list/ca
method find
allow *

# allow all nodes to store their reports
path /report
method save
allow *

# JJM Lock down the "files" fileserver mount exported from filserver.conf
# Remember, this file is parsed top to bottom and the first match "wins" so
# more specific rules need to be above more generalized rules.
# The following two rules mean the agent must posses a signed certificate and
# must be connecting from the 192.168.0.0/16 subnet.
path /file_metadata/files
auth yes
allow_ip 10.101.0.0/24
allow_ip 10.103.0.0/24

path /file_content/files
auth yes
allow_ip 10.101.0.0/24
allow_ip 10.103.0.0/24

# unconditionally allow access to all file services
# which means in practice that fileserver.conf will
# still be used
path /file
allow *

### Unauthenticated ACL, for clients for which the current master doesn't
### have a valid certificate; we allow authenticated users, too, because
### there isn't a great harm in letting that request through.

# allow access to the master CA
path /certificate/ca
auth any
method find
allow *

path /certificate/
auth any
method find
allow *

path /certificate_request
auth any
method find, save
allow *

# this one is not stricly necessary, but it has the merit
# of showing the default policy, which is deny everything else
path /
auth any


# References

 * [default auth.conf in 
3.0.x](https://github.com/puppetlabs/puppet/blob/3.0.x/conf/auth.conf)
 * [puppet-users discussion - Puppet 3.0: Not authorized to call find on 
/file_metadata, more 
issues](https://groups.google.com/d/topic/puppet-users/eQpr0-zd3dM/discussion)
 * [REST Access Control](http://docs.puppetlabs.com/guides/rest_auth_conf.html)


Bug #16667: Misleading error message "Not authorized to call find" after 
upgrading from 2.7 to 3.0
https://projects.puppetlabs.com/issues/16667#change-74837

Author: Jeff McCune
Status: Investigating
Priority: Normal
Assignee: 
Category: error reporting
Target version: 3.0.x
Affected Puppet version: 3.0.0
Keywords: 
Branch: 


# Overview

When we took out the deprecation warning for the modules path element in source 
URI's of file resources, we didn't replace it with a friendly error message.

# Expected behavior

In 2.7 t

[Puppet - Bug #16992] (Needs More Information) Puppet agents do not appear to work properly on Centos 6.3

2012-10-24 Thread tickets 

Issue #16992 has been updated by Josh Cooper.

Status changed from Unreviewed to Needs More Information
Assignee deleted (Josh Cooper)
Priority changed from Urgent to Normal
Target version deleted (2.7.20)

 Hi Alex, Can you paste or attach the relevant section of your manifest 
corresponding to `Name or service not known Could not retrieve file metadata 
for puppet:///modules/iptables/fragments/039_in_ssh_intranet: getaddrinfo: Name 
or service not known at /etc/puppet/modules/iptables/manifests/init.pp:13`

Since you are using a URI of the form `puppet:///modules/...`, puppet will use 
the `server` setting to connect to the puppetmaster. By default, this is 
`puppet`, but run the following to confirm: `puppet agent --configprint server`.

Likely you have a DNS configuration issue preventing the agent from resolving 
the master's IP address.

Bug #16992: Puppet agents do not appear to work properly on Centos 6.3
https://projects.puppetlabs.com/issues/16992#change-74815

Author: Alex Antonov
Status: Needs More Information
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 2.7.19
Keywords: 
Branch: 


Hi. 
I have the same issue as one described in ticket "Bug #15608". But I don't have 
rotate option in my /etc/resolv.conf.
My puppet server system is:
# uname -a
Linux puppet 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 
x86_64 x86_64 x86_64 GNU/Linux
# lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:CentOS release 6.3 (Final)
Release:6.3
Codename:   Final

My package versions are:
puppet-server-2.7.19-1.el6.noarch
puppet-2.7.19-1.el6.noarch
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
foreman-0.4.2-0.1.noarch

Puppet server and foreman run on nginx 1.2.3 builded from sources with passenger
passenger (3.0.17)

Foreman runs as ENC.

Agent run test trace:
# puppet agent --test --debug
...
err: /File[/etc/iptables.d/039_in_ssh_intranet]: Could not evaluate: 
getaddrinfo: Name or service not known Could not retrieve file metadata for 
puppet:///modules/iptables/fragments/039_in_ssh_intranet: getaddrinfo: Name or 
service not known at /etc/puppet/modules/iptables/manifests/init.pp:13
...
notice: /Stage[main]/Iptables/Exec[rebuild_iptables]: Dependency 
File[/etc/iptables.d/039_in_ssh_intranet] has failures: true
warning: /Stage[main]/Iptables/Exec[rebuild_iptables]: Skipping because of 
failed dependencies
...

I cannot reproduce this error on every puppet agent run. It appears from time 
to time. Downgrade of glibc packages doesn't seem to resolve the 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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15513] (In Topic Branch Pending Review) Resource type 'cron' fails with 'target' parameter

2012-10-24 Thread tickets 

Issue #15513 has been updated by Nick Fagerlund.

Status changed from Ready for Documentation to In Topic Branch Pending Review



Bug #15513: Resource type 'cron' fails with 'target' parameter
https://projects.puppetlabs.com/issues/15513#change-74813

Author: Marc Richter
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Andrew  Parker
Category: cron
Target version: 3.0.x
Affected Puppet version: 2.7.13
Keywords: cron, target
Branch: https://github.com/puppetlabs/puppet/pull/1233


`cron { 'foo':
 ensure => present,
 command => '/etc/init.d/foo restart',  
 user => 'root',
 minute => '*/1440',
 target => '/etc/cron.d/foo',
}`

This should create the file '/etc/cron.d/foo'. In the yml report there's 
written that puppet has created the file, but it isn't there.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15513] Resource type 'cron' fails with 'target' parameter

2012-10-24 Thread tickets 

Issue #15513 has been updated by Nick Fagerlund.

Assignee changed from Michael Hall to Andrew  Parker
Target version changed from 2.7.x to 3.0.x

Andy, I've reviewed this. If there's gonna be a 3.0.2, I think it makes sense 
to drop it in there; the pull request is currently targeted at master. 

Once a decision is made about releases, this ticket is a simple 
rebase-merge-and-close.

Bug #15513: Resource type 'cron' fails with 'target' parameter
https://projects.puppetlabs.com/issues/15513#change-74812

Author: Marc Richter
Status: Ready for Documentation
Priority: Normal
Assignee: Andrew  Parker
Category: cron
Target version: 3.0.x
Affected Puppet version: 2.7.13
Keywords: cron, target
Branch: https://github.com/puppetlabs/puppet/pull/1233


`cron { 'foo':
 ensure => present,
 command => '/etc/init.d/foo restart',  
 user => 'root',
 minute => '*/1440',
 target => '/etc/cron.d/foo',
}`

This should create the file '/etc/cron.d/foo'. In the yml report there's 
written that puppet has created the file, but it isn't there.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15513] Resource type 'cron' fails with 'target' parameter

2012-10-24 Thread tickets 

Issue #15513 has been updated by Nick Fagerlund.

Branch set to https://github.com/puppetlabs/puppet/pull/1233



Bug #15513: Resource type 'cron' fails with 'target' parameter
https://projects.puppetlabs.com/issues/15513#change-74806

Author: Marc Richter
Status: Ready for Documentation
Priority: Normal
Assignee: Michael Hall
Category: cron
Target version: 2.7.x
Affected Puppet version: 2.7.13
Keywords: cron, target
Branch: https://github.com/puppetlabs/puppet/pull/1233


`cron { 'foo':
 ensure => present,
 command => '/etc/init.d/foo restart',  
 user => 'root',
 minute => '*/1440',
 target => '/etc/cron.d/foo',
}`

This should create the file '/etc/cron.d/foo'. In the yml report there's 
written that puppet has created the file, but it isn't there.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17183] (Unreviewed) static compiler ignore owner & group attributes on recursive file sources

2012-10-24 Thread tickets 

Issue #17183 has been reported by Erik Dalén.


Bug #17183: static compiler ignore owner & group attributes on recursive file 
sources
https://projects.puppetlabs.com/issues/17183

Author: Erik Dalén
Status: Unreviewed
Priority: Normal
Assignee: 
Category: compiler
Target version: 
Affected Puppet version: 3.0.1
Keywords: static_compiler
Branch: 


Example:


file { '/foo':
  source  => 'puppet:///modules/foo/bar',
  owner   => root,
  group   => root,
  recurse => true,
}


For a manifest like this the static compiler returns the owner and group that 
the files have on the puppetmaster filesystem instead of root:root. It works as 
expected using the regular compiler. Setting owner/group using resource 
defaults doesn't work either.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16635] pkgdmg provider doesn't honor http_proxy_host/http_proxy_port

2012-10-24 Thread tickets 

Issue #16635 has been updated by Clay Caviness.


When our machines (mostly laptops) are outside the corporate network, we push 
everything through a (local, encrypted) proxy. We have a wrapper script that 
runs puppet - it determines on/off corp, and adds the `--http_proxy_host` and 
`--http_proxy_port` command-line flags as necessary.

I think in puppet 3 those environment variables won’t be passed through, 
but I’m not sure about that.
I’d rather just use the settings if they exist, as it seems less ambiguous 
(should environment win over config?).

That these command-line arguments end up as environment variables is besides 
the point - command-line flags should override the config. We use command-line 
flags to override config settings quite commonly.

If this behavior isn't going to be supported in puppet 3, where should I file 
bugs requesting it?

Bug #16635: pkgdmg provider doesn't honor http_proxy_host/http_proxy_port
https://projects.puppetlabs.com/issues/16635#change-74798

Author: Clay Caviness
Status: Needs More Information
Priority: Normal
Assignee: Clay Caviness
Category: OSX
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


The pkgdmg provider doesn't honor http_proxy_host/http_proxy_port settings. The 
actual file is downloaded using an exec to curl, no proxy information is passed:
curl "-o", cached_source, "-C", "-", "-k", "-L", "-s", "--url", 
source

I copied `http_proxy_env`, `http_proxy_host`, and `http_proxy_port` functions 
from `puppet/forge/repository.rb` and added them to `pkgdmg.rb`, and tweaked 
the call to curl in `pkgdmg.rb`:
if http_proxy_host and not http_proxy_port
  curl "-o", cached_source, "-C", "-", "-k", "-L", "-s", "--url", source, 
"--proxy", http_proxy_host
elsif http_proxy_host and http_proxy_port
  curl "-o", cached_source, "-C", "-", "-k", "-L", "-s", "--url", source, 
"--proxy", "#{http_proxy_host}:#{http_proxy_port}"
else
  curl "-o", cached_source, "-C", "-", "-k", "-L", "-s", "--url", source
end


I attached my patched pkgdmg.rb. I don't really understand how the `commands 
:curl => "/usr/bin/curl"` and `curl 'foo', 'bar', 'baz'` stuff actually works, 
so there's probably a much smoother way to do this...


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17129] (In Topic Branch Pending Review) SSL REST API bails out completely on permissions errors

2012-10-24 Thread tickets 

Issue #17129 has been updated by Jeff Weiss.

Status changed from Needs More Information to In Topic Branch Pending Review
Assignee changed from Max Martin to Jeff Weiss
Branch set to https://github.com/puppetlabs/puppet/pull/1232



Bug #17129: SSL REST API bails out completely on permissions errors
https://projects.puppetlabs.com/issues/17129#change-74796

Author: Max Martin
Status: In Topic Branch Pending Review
Priority: Normal
Assignee: Jeff Weiss
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: https://github.com/puppetlabs/puppet/pull/1232


If the puppetmaster doesn't have permission to access any of the .pem files 
waiting in the requests directory (in this case, 
`/etc/puppetlabs/puppet/ssl/ca/requests`), it will bail out completely when all 
CSRs are requested by hitting `/certificate_statuses/all`. In this example, I 
have a number of .pem files which the puppetmaster can access, and one that it 
cannot:

root@master:/etc/puppetlabs/puppet/ssl/ca/requests# ls -al
total 60
drwxr-xr-x 2 pe-puppet pe-puppet 4096 2012-10-19 21:18 .
drwxrwx--- 5 pe-puppet pe-puppet 4096 2012-10-19 01:55 ..
rw-r 1 peadmin peadmin 1590 2012-10-19 20:06 example_38463.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_46536.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_62602.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_66483.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_67152.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_69811.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_7469.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_78904.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90326.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90906.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_92088.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_93947.pem


when I attempt to hit `certificate_statuses/all` for the production 
environment, the whole response is `Permission denied - 
/etc/puppetlabs/puppet/ssl/ca/requests/example_38463.pem` The API should be 
able handle the permissions error and return information about all the waiting 
CSRs, at least those with correct permissions. It should possibly also return 
information about the .pem file with incorrect permissions.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Facter - Feature #17177] Add MTU information to interfaces

2012-10-24 Thread tickets 

Issue #17177 has been updated by Francis Gulotta.


I've got a patch on github targeted at the master branch, I'll recreate it 
targeting 2.x and submit a pull if this is acceptable.

https://github.com/reconbot/facter/commit/eb34e19f26c0f6c9b0fa8cca997e38a6ca5bfd97

Feature #17177: Add MTU information to interfaces
https://projects.puppetlabs.com/issues/17177#change-74794

Author: Francis Gulotta
Status: Unreviewed
Priority: Normal
Assignee: Francis Gulotta
Category: interface
Target version: 
Keywords: mtu interfaces
Branch: 
Affected Facter version: 2.0.0rc3


I'd like to add the mtu label for Util::IP for linux, bsd and sunos. These 
platforms already provide the mtu information for each interface in commands we 
run. Currently ignore it. Id also like to add mtu to the list of attributes 
provided in interfaces.rb.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Facter - Feature #17177] (Unreviewed) Add MTU information to interfaces

2012-10-24 Thread tickets 

Issue #17177 has been reported by Francis Gulotta.


Feature #17177: Add MTU information to interfaces
https://projects.puppetlabs.com/issues/17177

Author: Francis Gulotta
Status: Unreviewed
Priority: Normal
Assignee: Francis Gulotta
Category: interface
Target version: 
Keywords: mtu interfaces
Branch: 
Affected Facter version: 2.0.0rc3


I'd like to add the mtu label for Util::IP for linux, bsd and sunos. These 
platforms already provide the mtu information for each interface in commands we 
run. Currently ignore it. Id also like to add mtu to the list of attributes 
provided in interfaces.rb.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17129] SSL REST API bails out completely on permissions errors

2012-10-24 Thread tickets 

Issue #17129 has been updated by Jeff Weiss.


I believe we can add a FileTest.readable? to 
lib/puppet/indrector/ssl_file#search to fix this. 

Bug #17129: SSL REST API bails out completely on permissions errors
https://projects.puppetlabs.com/issues/17129#change-74787

Author: Max Martin
Status: Needs More Information
Priority: Normal
Assignee: Max Martin
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


If the puppetmaster doesn't have permission to access any of the .pem files 
waiting in the requests directory (in this case, 
`/etc/puppetlabs/puppet/ssl/ca/requests`), it will bail out completely when all 
CSRs are requested by hitting `/certificate_statuses/all`. In this example, I 
have a number of .pem files which the puppetmaster can access, and one that it 
cannot:

root@master:/etc/puppetlabs/puppet/ssl/ca/requests# ls -al
total 60
drwxr-xr-x 2 pe-puppet pe-puppet 4096 2012-10-19 21:18 .
drwxrwx--- 5 pe-puppet pe-puppet 4096 2012-10-19 01:55 ..
rw-r 1 peadmin peadmin 1590 2012-10-19 20:06 example_38463.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_46536.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_62602.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_66483.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_67152.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_69811.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_7469.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_78904.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90326.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_90906.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 21:15 example_92088.pem
rw-r 1 pe-puppet pe-puppet 1590 2012-10-19 20:06 example_93947.pem


when I attempt to hit `certificate_statuses/all` for the production 
environment, the whole response is `Permission denied - 
/etc/puppetlabs/puppet/ssl/ca/requests/example_38463.pem` The API should be 
able handle the permissions error and return information about all the waiting 
CSRs, at least those with correct permissions. It should possibly also return 
information about the .pem file with incorrect permissions.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #15513] Resource type 'cron' fails with 'target' parameter

2012-10-24 Thread tickets 

Issue #15513 has been updated by Michael Hall.

Assignee changed from Nick Fagerlund to Michael Hall



Bug #15513: Resource type 'cron' fails with 'target' parameter
https://projects.puppetlabs.com/issues/15513#change-74785

Author: Marc Richter
Status: Ready for Documentation
Priority: Normal
Assignee: Michael Hall
Category: cron
Target version: 2.7.x
Affected Puppet version: 2.7.13
Keywords: cron, target
Branch: 


`cron { 'foo':
 ensure => present,
 command => '/etc/init.d/foo restart',  
 user => 'root',
 minute => '*/1440',
 target => '/etc/cron.d/foo',
}`

This should create the file '/etc/cron.d/foo'. In the yml report there's 
written that puppet has created the file, but it isn't there.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #17174] (Unreviewed) Global Web Brazil - Questions

2012-10-24 Thread tickets 

Issue #17174 has been reported by Joe Henderson.


Bug #17174: Global Web Brazil - Questions
https://projects.puppetlabs.com/issues/17174

Author: Joe Henderson
Status: Unreviewed
Priority: Normal
Assignee: 
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


Hello,
Can you answer the following questions for this prospect...

I am working on data center IT and we testing a puppet version of
enterprise and want to know which operating systems are supported and where
we can download the packages.

Below operating systems we're testing:

RHEL 4 - Support? Where Download agent package?
RHEL 5 - Testing OK
RHEL 6 - Testing OK
SLES 10 - Support? Where Download agent package?
SLES 11 - Testing OK
HP-UX 11.11 - Support? Where Download agent package?
HP-UX 11.V2 IA64 - Support? Where Download agent package?
AIX 5.2 - Support? Where Download agent package?
AIX 5.3 - Support? Where Download agent package?
AIX 7 - Support? Where Download agent package?
SOLARIS 8 - Support? Where Download agent package?
SOLARIS 9 - Support? Where Download agent package?
SOLARIS 10 - Testing OK


AND
Joe,

The test is ten, but will be more than two thousand in production.

As the problem is that documentation is not supported AIX and HP-UX puppet
agent.

Is that right?

In our environment we have a list that i sent earlier.

Do you tell the agents that are supported?

Thanks,

Joe Henderson
*Puppet Labs* | Portland, OR
joe.hender...@puppetlabs.com
971-277-6822

Get Puppet Certified...Find a Testing
Location


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #16752] (Accepted) Enhance OpenBSD package provider to use pkg.conf(5)

2012-10-24 Thread tickets 

Issue #16752 has been updated by eric sorenson.

Status changed from Requires CLA to be signed to Accepted
Assignee changed from Eric0 Sorenson to eric sorenson

Submitting online is all you need, thanks! Now you have an award next to your 
name in redmine. 

I'll work this into a pull request.



Feature #16752: Enhance OpenBSD package provider to use pkg.conf(5)
https://projects.puppetlabs.com/issues/16752#change-74783

Author: Jasper Lievisse Adriaanse
Status: Accepted
Priority: Normal
Assignee: eric sorenson
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


On OpenBSD it's possible to create a file called /etc/pkg.conf which lists paths
from which to install packages from. When a PKG_PATH is not set, pkg_add will
look in /etc/pkg.conf and use the path found there.

Currently the OpenBSD package provider in Puppet needs to have 'source' set and
will ignore /etc/pkg.conf, the attach patch adjusts this behavior. If no no 
'source'
was explicitly set, then /etc/pkg.conf will be consulted.

This patch was agreed upon by the maintainer of the puppet package in OpenBSD.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16605] Service-resource gets restarted because Puppet agent (wrongfully) concludes that the MD5SUM of a dependant File-resource has changed

2012-10-24 Thread tickets 

Issue #16605 has been updated by Peter Drenth.


Peter Drenth wrote:
> I was looking for a similar issue, but don;t you mean archive_files = 
> true?..( where filebucket is concerned?.



Bug #16605: Service-resource gets restarted because Puppet agent (wrongfully) 
concludes that the MD5SUM of a dependant File-resource has changed 
https://projects.puppetlabs.com/issues/16605#change-74778

Author: Egon Kastelijn
Status: Needs More Information
Priority: Normal
Assignee: Egon Kastelijn
Category: agent
Target version: 
Affected Puppet version: 2.7.18
Keywords: puppet agent md5sum wrong trigger file service
Branch: 


* Cause:
In our Puppet infrastructure we sometimes see some strange messages in our 
Puppet agent logs.
At the moment it occurs, the files on the Puppet master don't change, but 
somehow the Puppet agent mentions/concludes that the MD5SUM of a file has 
changed (from 'A' to 'B')
This is logged in the Puppet agent log.
When I quickly log into the Puppet agent machine and check the MD5SUM of the 
specified file, then the MD5SUM is still 'A' (the way it should be)
This itself does not really cause a problem.

* Effect:
The problem is that our recipes contain Service resources that depend on the 
File that gets 'changed'.
This triggers the Service to restart, which causes unwanted service disruptions.

* Log:

<..snip...> (notice): content changed '{md5}2ac665d04a88ad4cbec4bb214577efe6' 
to '{md5}7068b0d27e78eed563593c8da3f943ec'
<..snip..> (notice): Triggered 'refresh' from 1 events


* Infrastructure information:

RHEL5.8
  1x Puppet Master (webrick)
~40x Puppet Agent
facter-1.6.12-2.el5
puppet-2.7.18-1.el5
puppet-server-2.7.18-1.el5


* Reproducability:
It happens multiple times per week, but on different files and at different 
moments of the day.



-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16605] Service-resource gets restarted because Puppet agent (wrongfully) concludes that the MD5SUM of a dependant File-resource has changed

2012-10-24 Thread tickets 

Issue #16605 has been updated by Peter Drenth.


I was looking for a similar issue, but don;t you mean archive_files = true?..( 
wehre filebucket is concerned?.

Bug #16605: Service-resource gets restarted because Puppet agent (wrongfully) 
concludes that the MD5SUM of a dependant File-resource has changed 
https://projects.puppetlabs.com/issues/16605#change-74777

Author: Egon Kastelijn
Status: Needs More Information
Priority: Normal
Assignee: Egon Kastelijn
Category: agent
Target version: 
Affected Puppet version: 2.7.18
Keywords: puppet agent md5sum wrong trigger file service
Branch: 


* Cause:
In our Puppet infrastructure we sometimes see some strange messages in our 
Puppet agent logs.
At the moment it occurs, the files on the Puppet master don't change, but 
somehow the Puppet agent mentions/concludes that the MD5SUM of a file has 
changed (from 'A' to 'B')
This is logged in the Puppet agent log.
When I quickly log into the Puppet agent machine and check the MD5SUM of the 
specified file, then the MD5SUM is still 'A' (the way it should be)
This itself does not really cause a problem.

* Effect:
The problem is that our recipes contain Service resources that depend on the 
File that gets 'changed'.
This triggers the Service to restart, which causes unwanted service disruptions.

* Log:

<..snip...> (notice): content changed '{md5}2ac665d04a88ad4cbec4bb214577efe6' 
to '{md5}7068b0d27e78eed563593c8da3f943ec'
<..snip..> (notice): Triggered 'refresh' from 1 events


* Infrastructure information:

RHEL5.8
  1x Puppet Master (webrick)
~40x Puppet Agent
facter-1.6.12-2.el5
puppet-2.7.18-1.el5
puppet-server-2.7.18-1.el5


* Reproducability:
It happens multiple times per week, but on different files and at different 
moments of the day.



-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Bug #16992] Puppet agents do not appear to work properly on Centos 6.3

2012-10-24 Thread tickets 

Issue #16992 has been updated by Alex Antonov.

Assignee set to Josh Cooper
Target version set to 2.7.20



Bug #16992: Puppet agents do not appear to work properly on Centos 6.3
https://projects.puppetlabs.com/issues/16992#change-74776

Author: Alex Antonov
Status: Unreviewed
Priority: Urgent
Assignee: Josh Cooper
Category: 
Target version: 2.7.20
Affected Puppet version: 2.7.19
Keywords: 
Branch: 


Hi. 
I have the same issue as one described in ticket "Bug #15608". But I don't have 
rotate option in my /etc/resolv.conf.
My puppet server system is:
# uname -a
Linux puppet 2.6.32-279.5.2.el6.x86_64 #1 SMP Fri Aug 24 01:07:11 UTC 2012 
x86_64 x86_64 x86_64 GNU/Linux
# lsb_release -a
LSB Version:
:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description:CentOS release 6.3 (Final)
Release:6.3
Codename:   Final

My package versions are:
puppet-server-2.7.19-1.el6.noarch
puppet-2.7.19-1.el6.noarch
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
foreman-0.4.2-0.1.noarch

Puppet server and foreman run on nginx 1.2.3 builded from sources with passenger
passenger (3.0.17)

Foreman runs as ENC.

Agent run test trace:
# puppet agent --test --debug
...
err: /File[/etc/iptables.d/039_in_ssh_intranet]: Could not evaluate: 
getaddrinfo: Name or service not known Could not retrieve file metadata for 
puppet:///modules/iptables/fragments/039_in_ssh_intranet: getaddrinfo: Name or 
service not known at /etc/puppet/modules/iptables/manifests/init.pp:13
...
notice: /Stage[main]/Iptables/Exec[rebuild_iptables]: Dependency 
File[/etc/iptables.d/039_in_ssh_intranet] has failures: true
warning: /Stage[main]/Iptables/Exec[rebuild_iptables]: Skipping because of 
failed dependencies
...

I cannot reproduce this error on every puppet agent run. It appears from time 
to time. Downgrade of glibc packages doesn't seem to resolve the 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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.

[Puppet - Feature #16752] Enhance OpenBSD package provider to use pkg.conf(5)

2012-10-24 Thread tickets 

Issue #16752 has been updated by Jasper Lievisse Adriaanse.

Assignee changed from Jasper Lievisse Adriaanse to Eric0 Sorenson

Hi,

I've hit the "Accept" button on the CLA page, is that sufficient or do I need 
to send the signed document too?

Also, the patch has been committed to OpenBSD here: 
http://marc.info/?l=openbsd-ports-cvs&m=134968613529723&w=2
and it was discussed in a face to face discussion. Would you like me to have 
Robert Nagy (the maintainer of Puppet)
in OpenBSD to confirm this patch in this ticket here too?

Thank you.

Feature #16752: Enhance OpenBSD package provider to use pkg.conf(5)
https://projects.puppetlabs.com/issues/16752#change-74775

Author: Jasper Lievisse Adriaanse
Status: Requires CLA to be signed
Priority: Normal
Assignee: Eric0 Sorenson
Category: 
Target version: 
Affected Puppet version: 
Keywords: 
Branch: 


On OpenBSD it's possible to create a file called /etc/pkg.conf which lists paths
from which to install packages from. When a PKG_PATH is not set, pkg_add will
look in /etc/pkg.conf and use the path found there.

Currently the OpenBSD package provider in Puppet needs to have 'source' set and
will ignore /etc/pkg.conf, the attach patch adjusts this behavior. If no no 
'source'
was explicitly set, then /etc/pkg.conf will be consulted.

This patch was agreed upon by the maintainer of the puppet package in OpenBSD.


-- 
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 post to this group, send email to puppet-bugs@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-bugs+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en.