[Puppet - Feature #20518] Bring in rich module documentation feature
Issue #20518 has been updated by Daniele Sluijters. Couldn't agree more. Puppet doc is a thorn in my side I'm itching to get rid of. I currently have a little tool that tries to parse the RDoc and transform it into Markdown so I can auto-generate README.md's etc. whith are automatically kept in sync with the docs but that solution is pretty hairy. There really needs to be a good documentation tool. We can just as easily use YARD for it so we can document Puppet modules and Puppet itself the same way but someone would have to write a parser for YARD to understand .pp files and the rest of the constructs. Feature #20518: Bring in rich module documentation feature https://projects.puppetlabs.com/issues/20518#change-91272 * Author: Yuri Arabadji * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: * Branch: `puppet doc --mode rdoc` just isn't enough. It doesn't work on recent ruby (1.9), it generates text documentation that isn't searchable/browseable/useful. What I'd like to see is something akin to a href=http://docs.puppetlabs.com/references/latest/type.html;Type Reference/a on Puppet website, but with TOC and menu on the left that would allow me to search and select what documentation section/type I'd like to browse. For ex., I'd like to see all functions that my module defines, their names, description, number of arguments, type. Same with custom types. The doc output format could be html, but any structural would work, too. Maybe xml with good xslt transform sheet? Or just JSON that can be easily converted to html? Would be nice to have, you know... -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20815] template for module does not comply with style guide
Issue #20815 has been updated by Garrett Honeycutt. Subject changed from template for module_name/tests/init.pp has more than 80 characters per line which is not in line with the style guide to template for module does not comply with style guide Bug #20815: template for module does not comply with style guide https://projects.puppetlabs.com/issues/20815#change-91273 * Author: Garrett Honeycutt * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: style, module * Branch: Running `rake lint` on any code created with `puppet module generate` produces the following warnings. pre tests/init.pp - WARNING: line has more than 80 characters on line 5 tests/init.pp - WARNING: line has more than 80 characters on line 6 tests/init.pp - WARNING: line has more than 80 characters on line 9 /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20815] template for module does not comply with style guide
Issue #20815 has been updated by Garrett Honeycutt. `manifests/init.pp` also had some long lines and was missing a comma after parameter in the example. Bug #20815: template for module does not comply with style guide https://projects.puppetlabs.com/issues/20815#change-91274 * Author: Garrett Honeycutt * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: style, module * Branch: Running `rake lint` on any code created with `puppet module generate` produces the following warnings. pre tests/init.pp - WARNING: line has more than 80 characters on line 5 tests/init.pp - WARNING: line has more than 80 characters on line 6 tests/init.pp - WARNING: line has more than 80 characters on line 9 /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20815] template for module does not comply with style guide
Issue #20815 has been updated by Garrett Honeycutt. PR https://github.com/puppetlabs/puppet/pull/1657 Bug #20815: template for module does not comply with style guide https://projects.puppetlabs.com/issues/20815#change-91275 * Author: Garrett Honeycutt * Status: Unreviewed * Priority: Normal * Assignee: * Category: * Target version: * Affected Puppet version: * Keywords: style, module * Branch: Running `rake lint` on any code created with `puppet module generate` produces the following warnings. pre tests/init.pp - WARNING: line has more than 80 characters on line 5 tests/init.pp - WARNING: line has more than 80 characters on line 6 tests/init.pp - WARNING: line has more than 80 characters on line 9 /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #17278] Double entry when using nagios_host
Issue #17278 has been updated by Jens Bräuer. Just for reference: This commit fixes the problem: https://github.com/puppetlabs/puppet/commit/a48b2fb Bug #17278: Double entry when using nagios_host https://projects.puppetlabs.com/issues/17278#change-91276 * Author: Alexandre Angel * Status: Investigating * Priority: Normal * Assignee: * Category: nagios * Target version: 3.x * Affected Puppet version: 3.0.1 * Keywords: nagios * Branch: Hello, Since upgrade to puppet 3, i have a problem with nagios_host used in local. I have a class creating nagios_host type. At first run, it works fine, nagios config file is ok. On the second run, one of them is added a second time to the nagios confif file like puppet failed to see it's already present in the file. If i try to not add that nagios_host, another one i add is added a second time. The bugging nagios_host is always the first in file generated. I guess it miss the first element when checking for existing host. Here is log from puppet agent --debug --verbose --no-daemonize concerning nagios_host : 1st run : pre Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event 2nd run : Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/notify: subscribes to Service[nagios3] /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]/ensure: created Info: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: Scheduling refresh of Service[nagios3] Debug: /Stage[main]//Node[webadmin.mydomain.com]/Nagios::Switch[sbx908.mydomain.com]/Nagios_host[sbx908.mydomain.com]: The container Nagios::Switch[sbx908.mydomain.com] will propagate my refresh event /Stage[main]/Nagios::Target/Nagios_host[webadmin.mydomain.com]/parents: parents changed ['sbx908.mydomain.com'] to 'sbx908.mydomain.com' Debug: Nagios::Switch[sbx908.mydomain.com]: The container Node[webadmin.mydomain.com] will propagate my refresh event /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20818] (Unreviewed) The short version of --environment argument (--env) is not working in puppet 3
Issue #20818 has been reported by Marc Villacorta. Bug #20818: The short version of --environment argument (--env) is not working in puppet 3 https://projects.puppetlabs.com/issues/20818 * Author: Marc Villacorta * Status: Unreviewed * Priority: Normal * Assignee: * Category: agent * Target version: * Affected Puppet version: 3.1.1 * Keywords: environment * Branch: I am used to invoke my environment like this: code puppet agent -t --env marc_villacorta /code But after upgrading to puppet 3 it silently defaults to 'production' environment. However, it works fine if I use: code puppet agent -t --environment marc_villacorta /code -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20818] (Duplicate) The short version of --environment argument (--env) is not working in puppet 3
Issue #20818 has been updated by Charlie Sharpsteen. Status changed from Unreviewed to Duplicate Assignee set to Charlie Sharpsteen Currently the puppet option parser is accepting partial matches, but silently discarding them. The best way to specify flags is to consult `puppet help` or the [configuration documentation](http://docs.puppetlabs.com/references/stable/configuration.html) and use the exact names specified therein. Marking as a duplicate of #19306. Bug #20818: The short version of --environment argument (--env) is not working in puppet 3 https://projects.puppetlabs.com/issues/20818#change-91283 * Author: Marc Villacorta * Status: Duplicate * Priority: Normal * Assignee: Charlie Sharpsteen * Category: agent * Target version: * Affected Puppet version: 3.1.1 * Keywords: environment * Branch: I am used to invoke my environment like this: code puppet agent -t --env marc_villacorta /code But after upgrading to puppet 3 it silently defaults to 'production' environment. However, it works fine if I use: code puppet agent -t --environment marc_villacorta /code -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20815] (In Topic Branch Pending Review) template for module does not comply with style guide
Issue #20815 has been updated by Charlie Sharpsteen. Category set to module tool Status changed from Unreviewed to In Topic Branch Pending Review Branch set to https://github.com/puppetlabs/puppet/pull/1657 Thanks a bunch for the pull request! Bug #20815: template for module does not comply with style guide https://projects.puppetlabs.com/issues/20815#change-91284 * Author: Garrett Honeycutt * Status: In Topic Branch Pending Review * Priority: Normal * Assignee: * Category: module tool * Target version: * Affected Puppet version: * Keywords: style, module * Branch: https://github.com/puppetlabs/puppet/pull/1657 Running `rake lint` on any code created with `puppet module generate` produces the following warnings. pre tests/init.pp - WARNING: line has more than 80 characters on line 5 tests/init.pp - WARNING: line has more than 80 characters on line 6 tests/init.pp - WARNING: line has more than 80 characters on line 9 /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20815] (Merged - Pending Release) template for module does not comply with style guide
Issue #20815 has been updated by Adrien Thebo. Status changed from In Topic Branch Pending Review to Merged - Pending Release Target version set to 3.3.0 Merged into master in 2dd097c; this should be released in 3.3.0. Bug #20815: template for module does not comply with style guide https://projects.puppetlabs.com/issues/20815#change-91289 * Author: Garrett Honeycutt * Status: Merged - Pending Release * Priority: Normal * Assignee: * Category: module tool * Target version: 3.3.0 * Affected Puppet version: * Keywords: style, module * Branch: https://github.com/puppetlabs/puppet/pull/1657 Running `rake lint` on any code created with `puppet module generate` produces the following warnings. pre tests/init.pp - WARNING: line has more than 80 characters on line 5 tests/init.pp - WARNING: line has more than 80 characters on line 6 tests/init.pp - WARNING: line has more than 80 characters on line 9 /pre -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20760] AIX extended user attributes may not contain spaces and/or brackets in puppet definitions
Issue #20760 has been updated by Charlie Sharpsteen.
Description updated
Bug #20760: AIX extended user attributes may not contain spaces and/or brackets
in puppet definitions
https://projects.puppetlabs.com/issues/20760#change-91290
* Author: Thomas Bettray
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 2.7.20
* Keywords:
* Branch:
When trying to update the extended attributes of a user, puppet will fail to
apply this if one of the present attributes contains spaces and/or brackets
(not sure which one of them breaks it...). Puppet version is 2.7.20 running on
AIX 6.1 TL8 SP2.
pre
# lsuser test
test id=12345 pgrp=staff groups=staff home=/home/test shell=/bin/ksh login=true
su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak
ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=(VAS
OR files) logintimes= loginretries=5 pwdwarntime=7 account_locked=false
minage=0 maxage=12 maxexpired=2 minalpha=2 minother=2 mindiff=2 maxrepeats=4
minlen=7 histexpire=1 histsize=5 pwdchecks= dictionlist=/usr/local/wordlist
default_roles= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=-1
nofiles=2000 unsuccessful_login_count=2 roles=
/pre
The interesting part is the SYSTEM=(VAS OR files) here containing spaces and
brackets.
if trying to apply the following rules:
pre
# cat usertest.pp
user {'test':
ensure = present,
uid= '12345',
gid= 'staff',
groups = 'staff',
home = '/home/test',
attributes = ['gecos=Test'],
}
/pre
This will fail:
pre
# puppet apply /tmp/usertest.pp
warning: iconv doesn't seem to support UTF-8/UTF-16 conversions
notice: /Stage[main]//User[test]/home: home changed '/home/newtest' to
'/home/test'
err: /Stage[main]//User[test]/attributes: change from rlogin=true
registry=files account_locked=false default_roles= auth1=SYSTEM minlen=7
admin=false maxexpired=2 fsize=-1 auth2=NONE histexpire=1 stack=65536
sugroups=ALL SYSTEM=(VAS minalpha=2 cpu=-1 core=2097151 roles= logintimes=
histsize=5 daemon=true admgroups= minother=2 rss=-1 loginretries=5 pwdchecks=
data=262144 tpath=nosak mindiff=2 nofiles=2000 login=true su=true pwdwarntime=7
dictionlist=/usr/local/rwe/etc/config.words ttys=ALL umask=22 maxrepeats=4
unsuccessful_login_count=2 to default_roles= account_locked=false
registry=files rlogin=true minlen=7 auth1=SYSTEM fsize=-1 maxexpired=2
admin=false stack=65536 histexpire=1 auth2=NONE roles= core=2097151 cpu=-1
minalpha=2 SYSTEM=(VAS sugroups=ALL histsize=5 logintimes= rss=-1 minother=2
admgroups= daemon=true data=262144 pwdchecks= loginretries=5 nofiles=2000
mindiff=2 tpath=nosak dictionlist=/usr/local/rwe/etc/config.words pwdwarntime=7
su=true login=true gecos=Test
unsuccessful_login_count=2 maxrepeats=4 umask=22 ttys=ALL failed: Could not
set attributes on user[test]: Execution of '/usr/bin/chuser rlogin=true
registry=files account_locked=false default_roles= auth1=SYSTEM minlen=7
admin=false maxexpired=2 fsize=-1 auth2=NONE histexpire=1 stack=65536
sugroups=ALL SYSTEM=(VAS minalpha=2 cpu=-1 core=2097151 roles= logintimes=
histsize=5 daemon=true admgroups= minother=2 rss=-1 loginretries=5 pwdchecks=
data=262144 tpath=nosak mindiff=2 nofiles=2000 login=true su=true pwdwarntime=7
dictionlist=/usr/local/rwe/etc/config.words ttys=ALL umask=22 maxrepeats=4
unsuccessful_login_count=2 gecos=Test test' returned 22: Error changing
SYSTEM to (VAS : Value is invalid.
notice: Finished catalog run in 0.72 seconds
/pre
A possible workaround:
pre
# cat usertest2.pp
user {'test':
ensure = present,
uid= '12345',
gid= 'staff',
groups = 'staff',
home = '/home/newtest',
attributes = ['gecos=Test', 'SYSTEM=(VAS OR files)'],
}
# puppet apply /tmp/usertest2.pp
warning: iconv doesn't seem to support UTF-8/UTF-16 conversions
notice: /Stage[main]//User[test]/home: home changed '/home/test' to
'/home/newtest'
notice: /Stage[main]//User[test]/attributes: attributes changed 'rlogin=true
registry=files account_locked=false default_roles= auth1=SYSTEM minlen=7
admin=false maxexpired=2 fsize=-1 auth2=NONE histexpire=1 stack=65536
sugroups=ALL SYSTEM=(VAS minalpha=2 cpu=-1 core=2097151 roles= logintimes=
histsize=5 daemon=true admgroups= minother=2 rss=-1 loginretries=5 pwdchecks=
data=262144 tpath=nosak mindiff=2 nofiles=2000 login=true su=true pwdwarntime=7
dictionlist=/usr/local/rwe/etc/config.words ttys=ALL umask=22 maxrepeats=4
unsuccessful_login_count=2' to 'default_roles= account_locked=false
registry=files rlogin=true minlen=7 auth1=SYSTEM fsize=-1 maxexpired=2
admin=false stack=65536 histexpire=1 auth2=NONE roles= core=2097151 cpu=-1
minalpha=2 SYSTEM=(VAS OR files) sugroups=ALL histsize=5 logintimes= rss=-1
minother=2 admgroups= daemon=true data=262144 pwdchecks= loginretries=5
nofiles=2000 mindiff=2 tpath=nosak
[Puppet - Bug #20551] (Needs More Information) Puppet + Nagios: false removals reported with every run
Issue #20551 has been updated by Charlie Sharpsteen.
Subject changed from Puppet + Nagios: to Puppet + Nagios: false removals
reported with every run
Category set to nagios
Status changed from Unreviewed to Needs More Information
Assignee set to Justin Honold
Justin, for the machines exhibiting this behavior, which version of Ruby and
which operating system is in use?
Bug #20551: Puppet + Nagios: false removals reported with every run
https://projects.puppetlabs.com/issues/20551#change-91291
* Author: Justin Honold
* Status: Needs More Information
* Priority: Normal
* Assignee: Justin Honold
* Category: nagios
* Target version:
* Affected Puppet version: 3.1.1
* Keywords:
* Branch:
pre
Notice: /Nagios_hostgroup[[xl]]/ensure: removed
Info: FileBucket adding {md5}6d7d765c5e7bb37e386c7bb384b6968e
Notice: /Nagios_host[[my-server]]/ensure: removed
Info: FileBucket adding {md5}72fd636eb900b7906f74171903b130bf
Notice: /Nagios_servicegroup[[puppet]]/ensure: removed
Info: FileBucket adding {md5}110411c086f7e0b304ee2e3fe755819b
Notice: /Nagios_contactgroup[[admins]]/ensure: removed
Info: FileBucket adding {md5}b16b3221b0601711da33361a7a6a1161
Notice: /Nagios_contact[[my-contact]]/ensure: removed
Info: FileBucket adding {md5}65d3a2ffdf05c94856380e8e0508aa68
Notice: /Nagios_service[[check_ssh]]/ensure: removed
Info: FileBucket adding {md5}f5790923c44bafa4c48e5c7e52034c52
Notice: /Nagios_command[[check_dummy]]/ensure: removed
Info: FileBucket adding {md5}44466659949a9119cc0bb87a767f174a
Notice: Finished catalog run in 17.68 seconds
/pre
These removes - which aren't actually removed, and are actually defined and
in use - are present on every run on this system.
I'm guessing it could be of note that I am using 'purge = true' for 'nagios_'
commands.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20760] (Duplicate) AIX extended user attributes may not contain spaces and/or brackets in puppet definitions
Issue #20760 has been updated by Jeff Weiss.
Status changed from Unreviewed to Duplicate
Though perhaps not immediately clean, this is actually a duplicate of #20442.
The underlying issue is that Puppet (prior to the fix of #20442) was trying to
managed extended attributes that it wasn't explicitly told to manage (bad
Puppet!). The fix of #20442 ensures that Puppet will only managed extended
attributes it has been explicitly told to manage and leave other extended
attributes as is.
Bug #20760: AIX extended user attributes may not contain spaces and/or brackets
in puppet definitions
https://projects.puppetlabs.com/issues/20760#change-91294
* Author: Thomas Bettray
* Status: Duplicate
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 2.7.20
* Keywords:
* Branch:
When trying to update the extended attributes of a user, puppet will fail to
apply this if one of the present attributes contains spaces and/or brackets
(not sure which one of them breaks it...). Puppet version is 2.7.20 running on
AIX 6.1 TL8 SP2.
pre
# lsuser test
test id=12345 pgrp=staff groups=staff home=/home/test shell=/bin/ksh login=true
su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak
ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=(VAS
OR files) logintimes= loginretries=5 pwdwarntime=7 account_locked=false
minage=0 maxage=12 maxexpired=2 minalpha=2 minother=2 mindiff=2 maxrepeats=4
minlen=7 histexpire=1 histsize=5 pwdchecks= dictionlist=/usr/local/wordlist
default_roles= fsize=-1 cpu=-1 data=262144 stack=65536 core=2097151 rss=-1
nofiles=2000 unsuccessful_login_count=2 roles=
/pre
The interesting part is the SYSTEM=(VAS OR files) here containing spaces and
brackets.
if trying to apply the following rules:
pre
# cat usertest.pp
user {'test':
ensure = present,
uid= '12345',
gid= 'staff',
groups = 'staff',
home = '/home/test',
attributes = ['gecos=Test'],
}
/pre
This will fail:
pre
# puppet apply /tmp/usertest.pp
warning: iconv doesn't seem to support UTF-8/UTF-16 conversions
notice: /Stage[main]//User[test]/home: home changed '/home/newtest' to
'/home/test'
err: /Stage[main]//User[test]/attributes: change from rlogin=true
registry=files account_locked=false default_roles= auth1=SYSTEM minlen=7
admin=false maxexpired=2 fsize=-1 auth2=NONE histexpire=1 stack=65536
sugroups=ALL SYSTEM=(VAS minalpha=2 cpu=-1 core=2097151 roles= logintimes=
histsize=5 daemon=true admgroups= minother=2 rss=-1 loginretries=5 pwdchecks=
data=262144 tpath=nosak mindiff=2 nofiles=2000 login=true su=true pwdwarntime=7
dictionlist=/usr/local/rwe/etc/config.words ttys=ALL umask=22 maxrepeats=4
unsuccessful_login_count=2 to default_roles= account_locked=false
registry=files rlogin=true minlen=7 auth1=SYSTEM fsize=-1 maxexpired=2
admin=false stack=65536 histexpire=1 auth2=NONE roles= core=2097151 cpu=-1
minalpha=2 SYSTEM=(VAS sugroups=ALL histsize=5 logintimes= rss=-1 minother=2
admgroups= daemon=true data=262144 pwdchecks= loginretries=5 nofiles=2000
mindiff=2 tpath=nosak dictionlist=/usr/local/rwe/etc/config.words pwdwarntime=7
su=true login=true gecos=Test
unsuccessful_login_count=2 maxrepeats=4 umask=22 ttys=ALL failed: Could not
set attributes on user[test]: Execution of '/usr/bin/chuser rlogin=true
registry=files account_locked=false default_roles= auth1=SYSTEM minlen=7
admin=false maxexpired=2 fsize=-1 auth2=NONE histexpire=1 stack=65536
sugroups=ALL SYSTEM=(VAS minalpha=2 cpu=-1 core=2097151 roles= logintimes=
histsize=5 daemon=true admgroups= minother=2 rss=-1 loginretries=5 pwdchecks=
data=262144 tpath=nosak mindiff=2 nofiles=2000 login=true su=true pwdwarntime=7
dictionlist=/usr/local/rwe/etc/config.words ttys=ALL umask=22 maxrepeats=4
unsuccessful_login_count=2 gecos=Test test' returned 22: Error changing
SYSTEM to (VAS : Value is invalid.
notice: Finished catalog run in 0.72 seconds
/pre
A possible workaround:
pre
# cat usertest2.pp
user {'test':
ensure = present,
uid= '12345',
gid= 'staff',
groups = 'staff',
home = '/home/newtest',
attributes = ['gecos=Test', 'SYSTEM=(VAS OR files)'],
}
# puppet apply /tmp/usertest2.pp
warning: iconv doesn't seem to support UTF-8/UTF-16 conversions
notice: /Stage[main]//User[test]/home: home changed '/home/test' to
'/home/newtest'
notice: /Stage[main]//User[test]/attributes: attributes changed 'rlogin=true
registry=files account_locked=false default_roles= auth1=SYSTEM minlen=7
admin=false maxexpired=2 fsize=-1 auth2=NONE histexpire=1 stack=65536
sugroups=ALL SYSTEM=(VAS minalpha=2 cpu=-1 core=2097151 roles= logintimes=
histsize=5 daemon=true admgroups= minother=2 rss=-1 loginretries=5 pwdchecks=
data=262144 tpath=nosak mindiff=2 nofiles=2000 login=true su=true pwdwarntime=7
dictionlist=/usr/local/rwe/etc/config.words ttys=ALL umask=22
[Puppet - Bug #19306] (Accepted) Puppet option parser accepts partial matches but doesn't use them to alter configuration values
Issue #19306 has been updated by Charlie Sharpsteen. Status changed from Unreviewed to Accepted Affected Puppet version changed from 3.1.0 to 3.0.0 Also appears that partial matching works in the 2.7.x series but not 3.x. Bisected the change in behavior down to [cb3ce74](https://github.com/puppetlabs/puppet/commit/cb3ce74). Appears this is where the split between OptionParser and Trollop was introduced. Bug #19306: Puppet option parser accepts partial matches but doesn't use them to alter configuration values https://projects.puppetlabs.com/issues/19306#change-91296 * Author: Charlie Sharpsteen * Status: Accepted * Priority: Normal * Assignee: * Category: Faces * Target version: * Affected Puppet version: 3.0.0 * Keywords: options * Branch: This popped up during investigation of #19153. When a Puppet command such as `agent` encounters an unknown option, it throws a warning: # puppet agent --foo Error: Could not parse application options: invalid option: --foo Similarly, when it encounters a known option, it will alter a config value: # puppet agent --configprint daemonize true # puppet agent --no-daemonize --configprint daemonize false However, the parser will also accept partial matches: # puppet agent --no-daemoniz --configprint daemonize true # puppet agent --no-daemon --configprint daemonize true # puppet agent --no-da --configprint daemonize true Edge Cases: # puppet agent --no-daemonizer --configprint daemonize Error: Could not parse application options: invalid option: --no-daemonizer # puppet agent --no-d --configprint daemonize Error: Could not parse application options: ambiguous option: --no-d The problems with partial matching is that the flags don't alter configuration values and no warning or error is emitted to alert users that their input is incorrect or that their intentions are not being honored. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20607] (Accepted) Fails to create lastrunfile with mode
Issue #20607 has been updated by Charlie Sharpsteen.
Status changed from Investigating to Accepted
Assignee deleted (Charlie Sharpsteen)
Looks like we have code in `util/symbolic_file_mode.rb` that can validate file
modes expressed as strings and throw sane error messages. However, this file
also includes the top level `util.rb`---which is where the `replace_file`
method that throws the error reported in this issue lives.
The code in symbolic_file_mode is very useful and should be re-factored to be
generally available without worrying about circular `require` statements.
Bug #20607: Fails to create lastrunfile with mode
https://projects.puppetlabs.com/issues/20607#change-91297
* Author: Dan Carley
* Status: Accepted
* Priority: Normal
* Assignee:
* Category: settings
* Target version:
* Affected Puppet version: 2.7.19
* Keywords:
* Branch:
Puppet fails to create `lastrunfile` when a mode is specified and the file
doesn't already exist:
pre
dcarley-mba:puppet dcarley$ cat ~/.puppet/puppet.conf
[main]
lastrunfile = $statedir/last_run_summary.yaml { mode = 644 }
dcarley-mba:puppet dcarley$ rm ~/.puppet/var/state/last_run_summary.yaml
dcarley-mba:puppet dcarley$ echo | b puppet apply --trace
Notice: Finished catalog run in 0.02 seconds
Error: Could not save last run local report: undefined method `' for
644:String
/Users/dcarley/projects/ext/puppet/lib/puppet/util.rb:424:in `replace_file'
/Users/dcarley/projects/ext/puppet/lib/puppet/configurer.rb:207:in
`save_last_run_summary'
/Users/dcarley/projects/ext/puppet/lib/puppet/configurer.rb:199:in `send_report'
/Users/dcarley/projects/ext/puppet/lib/puppet/configurer.rb:194:in `run'
/Users/dcarley/projects/ext/puppet/lib/puppet/application/apply.rb:265:in
`apply_catalog'
/Users/dcarley/projects/ext/puppet/lib/puppet/application/apply.rb:213:in `main'
/Users/dcarley/projects/ext/puppet/lib/puppet/application/apply.rb:146:in
`run_command'
/Users/dcarley/projects/ext/puppet/lib/puppet/application.rb:364:in `block (2
levels) in run'
/Users/dcarley/projects/ext/puppet/lib/puppet/application.rb:456:in
`plugin_hook'
/Users/dcarley/projects/ext/puppet/lib/puppet/application.rb:364:in `block in
run'
/Users/dcarley/projects/ext/puppet/lib/puppet/util.rb:504:in `exit_on_fail'
/Users/dcarley/projects/ext/puppet/lib/puppet/application.rb:364:in `run'
/Users/dcarley/projects/ext/puppet/lib/puppet/util/command_line.rb:132:in `run'
/Users/dcarley/projects/ext/puppet/lib/puppet/util/command_line.rb:86:in
`execute'
/Users/dcarley/projects/ext/puppet/bin/puppet:4:in `top (required)'
/Users/dcarley/projects/ext/puppet/vendor/bin/puppet:23:in `load'
/Users/dcarley/projects/ext/puppet/vendor/bin/puppet:23:in `main'
/pre
It's fine when the file does exist:
pre
dcarley-mba:puppet dcarley$ touch ~/.puppet/var/state/last_run_summary.yaml
dcarley-mba:puppet dcarley$ echo | b puppet apply --trace
Notice: Finished catalog run in 0.02 seconds
/pre
Observed with:
- Puppet 2.7.19 / Ruby 1.8.7
- Puppet 3.1.1 / Ruby 1.9.3
[`Puppet.settings.setting(:lastrunfile).mode`](https://github.com/puppetlabs/puppet/blob/3.1.1/lib/puppet/util.rb#L424)
returns a string when
[`Puppet::Util.replace_file`](https://github.com/puppetlabs/puppet/blob/3.1.1/lib/puppet/util.rb#L424)
expects an integer. This is closely related to #15539.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20551] Puppet + Nagios: false removals reported with every run
Issue #20551 has been updated by Justin Honold.
ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux]
CentOS release 6.4 (Final)
Bug #20551: Puppet + Nagios: false removals reported with every run
https://projects.puppetlabs.com/issues/20551#change-91298
* Author: Justin Honold
* Status: Needs More Information
* Priority: Normal
* Assignee: Justin Honold
* Category: nagios
* Target version:
* Affected Puppet version: 3.1.1
* Keywords:
* Branch:
pre
Notice: /Nagios_hostgroup[[xl]]/ensure: removed
Info: FileBucket adding {md5}6d7d765c5e7bb37e386c7bb384b6968e
Notice: /Nagios_host[[my-server]]/ensure: removed
Info: FileBucket adding {md5}72fd636eb900b7906f74171903b130bf
Notice: /Nagios_servicegroup[[puppet]]/ensure: removed
Info: FileBucket adding {md5}110411c086f7e0b304ee2e3fe755819b
Notice: /Nagios_contactgroup[[admins]]/ensure: removed
Info: FileBucket adding {md5}b16b3221b0601711da33361a7a6a1161
Notice: /Nagios_contact[[my-contact]]/ensure: removed
Info: FileBucket adding {md5}65d3a2ffdf05c94856380e8e0508aa68
Notice: /Nagios_service[[check_ssh]]/ensure: removed
Info: FileBucket adding {md5}f5790923c44bafa4c48e5c7e52034c52
Notice: /Nagios_command[[check_dummy]]/ensure: removed
Info: FileBucket adding {md5}44466659949a9119cc0bb87a767f174a
Notice: Finished catalog run in 17.68 seconds
/pre
These removes - which aren't actually removed, and are actually defined and
in use - are present on every run on this system.
I'm guessing it could be of note that I am using 'purge = true' for 'nagios_'
commands.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20813] Defined type with recursion fails with duplicate declaration
Issue #20813 has been updated by Igor Muratov.
Another way to workaround the issue is to add one more directory to the SECOND
item like that:
/usr/local/bin
/usr/local/etc/conf
Bug #20813: Defined type with recursion fails with duplicate declaration
https://projects.puppetlabs.com/issues/20813#change-91299
* Author: Igor Muratov
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 2.7.21
* Keywords: defined types, recursion, mkdir_p
* Branch:
First of all let me say it fails in some situations, not always. Here is the
code which I have:
class filesystem {
File {
ensure = directory,
mode= '0755',
owner = 'root',
group = 'root',
}
# Recursive function creates chain of objects
define make_dir($owner=undef, $group=undef, $mode=undef) {
file { $name:
ensure = directory,
mode= $mode,
owner = $owner,
group = $group,
}
# Take parent directory name
$parent = regsubst($name, '(.+)(/[^/]+)$', '\1')
# Recursive call if object does not exist
if ( $parent != and ! defined(File[$parent])) {
make_dir { $parent:
mode = $mode,
owner = $owner,
group = $group,
}
File[$parent] - File[$name]
}
}
}
class filesystem::common inherits filesystem {
make_dir { [
'/usr/local/bin',
'/usr/local/etc',
]:
}
}
So, when I do have two directories with the same parent directory, the class
will fail:
Mogul:manifests user$ minicatv example.com filesystem::common
notice: looking up example.com...
err: Duplicate declaration: Filesystem::Make_dir[/usr/local] is already
declared in file /home/user/Dvl/my_test/modules/filesystem/manifests/init.pp at
line 63; cannot redeclare at
/home/user/Dvl/my_test/modules/filesystem/manifests/init.pp:63 on node
example.com
err: Try 'puppet help minicat compile' for usage
There is no issue with /usr but with the longest common part of items. The
workaround is to add the parent directory into the list like that:
/usr/local
/usr/local/bin
/usr/local/etc
That case all directory objects, including /usr, will be created with no
errors. It is not obvious to me where and why puppet fails and I only assuming
it could be a bug.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20551] Puppet + Nagios: false removals reported with every run
Issue #20551 has been updated by Charlie Sharpsteen.
Since you are using Ruby 1.9, I suspect you may be seeing behavior from #17871
where the Nagios types were spawning duplicates on each run due to changes in
array splatting between 1.8 and 1.9. The removes could be from `purge=true`
cleaning out the dupes.
Bug #20551: Puppet + Nagios: false removals reported with every run
https://projects.puppetlabs.com/issues/20551#change-91300
* Author: Justin Honold
* Status: Needs More Information
* Priority: Normal
* Assignee: Justin Honold
* Category: nagios
* Target version:
* Affected Puppet version: 3.1.1
* Keywords:
* Branch:
pre
Notice: /Nagios_hostgroup[[xl]]/ensure: removed
Info: FileBucket adding {md5}6d7d765c5e7bb37e386c7bb384b6968e
Notice: /Nagios_host[[my-server]]/ensure: removed
Info: FileBucket adding {md5}72fd636eb900b7906f74171903b130bf
Notice: /Nagios_servicegroup[[puppet]]/ensure: removed
Info: FileBucket adding {md5}110411c086f7e0b304ee2e3fe755819b
Notice: /Nagios_contactgroup[[admins]]/ensure: removed
Info: FileBucket adding {md5}b16b3221b0601711da33361a7a6a1161
Notice: /Nagios_contact[[my-contact]]/ensure: removed
Info: FileBucket adding {md5}65d3a2ffdf05c94856380e8e0508aa68
Notice: /Nagios_service[[check_ssh]]/ensure: removed
Info: FileBucket adding {md5}f5790923c44bafa4c48e5c7e52034c52
Notice: /Nagios_command[[check_dummy]]/ensure: removed
Info: FileBucket adding {md5}44466659949a9119cc0bb87a767f174a
Notice: Finished catalog run in 17.68 seconds
/pre
These removes - which aren't actually removed, and are actually defined and
in use - are present on every run on this system.
I'm guessing it could be of note that I am using 'purge = true' for 'nagios_'
commands.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20551] Puppet + Nagios: false removals reported with every run
Issue #20551 has been updated by Justin Honold.
I'll watch over there too - if you think this is a dupe, feel free to
link/close. Thanks!
Bug #20551: Puppet + Nagios: false removals reported with every run
https://projects.puppetlabs.com/issues/20551#change-91303
* Author: Justin Honold
* Status: Needs More Information
* Priority: Normal
* Assignee: Justin Honold
* Category: nagios
* Target version:
* Affected Puppet version: 3.1.1
* Keywords:
* Branch:
pre
Notice: /Nagios_hostgroup[[xl]]/ensure: removed
Info: FileBucket adding {md5}6d7d765c5e7bb37e386c7bb384b6968e
Notice: /Nagios_host[[my-server]]/ensure: removed
Info: FileBucket adding {md5}72fd636eb900b7906f74171903b130bf
Notice: /Nagios_servicegroup[[puppet]]/ensure: removed
Info: FileBucket adding {md5}110411c086f7e0b304ee2e3fe755819b
Notice: /Nagios_contactgroup[[admins]]/ensure: removed
Info: FileBucket adding {md5}b16b3221b0601711da33361a7a6a1161
Notice: /Nagios_contact[[my-contact]]/ensure: removed
Info: FileBucket adding {md5}65d3a2ffdf05c94856380e8e0508aa68
Notice: /Nagios_service[[check_ssh]]/ensure: removed
Info: FileBucket adding {md5}f5790923c44bafa4c48e5c7e52034c52
Notice: /Nagios_command[[check_dummy]]/ensure: removed
Info: FileBucket adding {md5}44466659949a9119cc0bb87a767f174a
Notice: Finished catalog run in 17.68 seconds
/pre
These removes - which aren't actually removed, and are actually defined and
in use - are present on every run on this system.
I'm guessing it could be of note that I am using 'purge = true' for 'nagios_'
commands.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20813] Defined type with recursion fails with duplicate declaration
Issue #20813 has been updated by Charlie Sharpsteen.
Description updated
Bug #20813: Defined type with recursion fails with duplicate declaration
https://projects.puppetlabs.com/issues/20813#change-91307
* Author: Igor Muratov
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 2.7.21
* Keywords: defined types, recursion, mkdir_p
* Branch:
First of all let me say it fails in some situations, not always. Here is the
code which I have:
pre
class filesystem {
File {
ensure = directory,
mode= '0755',
owner = 'root',
group = 'root',
}
# Recursive function creates chain of objects
define make_dir($owner=undef, $group=undef, $mode=undef) {
file { $name:
ensure = directory,
mode= $mode,
owner = $owner,
group = $group,
}
# Take parent directory name
$parent = regsubst($name, '(.+)(/[^/]+)$', '\1')
# Recursive call if object does not exist
if ( $parent != and ! defined(File[$parent])) {
make_dir { $parent:
mode = $mode,
owner = $owner,
group = $group,
}
File[$parent] - File[$name]
}
}
}
class filesystem::common inherits filesystem {
make_dir { [
'/usr/local/bin',
'/usr/local/etc',
]:
}
}
/pre
So, when I do have two directories with the same parent directory, the class
will fail:
pre
Mogul:manifests user$ minicatv example.com filesystem::common
notice: looking up example.com...
err: Duplicate declaration: Filesystem::Make_dir[/usr/local] is already
declared in file /home/user/Dvl/my_test/modules/filesystem/manifests/init.pp at
line 63; cannot redeclare at
/home/user/Dvl/my_test/modules/filesystem/manifests/init.pp:63 on node
example.com
err: Try 'puppet help minicat compile' for usage
There is no issue with /usr but with the longest common part of items. The
workaround is to add the parent directory into the list like that:
/usr/local
/usr/local/bin
/usr/local/etc
/pre
That case all directory objects, including /usr, will be created with no
errors. It is not obvious to me where and why puppet fails and I only assuming
it could be a bug.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20675] (Duplicate) Bug/question: No error or warning for self-requiring resources
Issue #20675 has been updated by Charlie Sharpsteen.
Status changed from Unreviewed to Duplicate
Assignee set to Charlie Sharpsteen
Closing as a duplicate of #14652.
Bug #20675: Bug/question: No error or warning for self-requiring resources
https://projects.puppetlabs.com/issues/20675#change-91308
* Author: Christian Flamm
* Status: Duplicate
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: compiler
* Target version:
* Affected Puppet version: 3.1.1
* Keywords: self-requirement dependency cycle
* Branch:
Is there any reason something like this...
class self_requirement_test {
$tmpfile = '/tmp/wtf'
file { $tmpfile: require = File[$tmpfile] }
}
... should not lead to an error or at least a warning? Isn't this just the
smallest dependency cycle?
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #6112] Puppet cert generate error message when it succeeds
Issue #6112 has been updated by Charlie Sharpsteen. Assignee set to Charlie Sharpsteen Bug #6112: Puppet cert generate error message when it succeeds https://projects.puppetlabs.com/issues/6112#change-91310 * Author: Jeff McCune * Status: Needs More Information * Priority: Normal * Assignee: Charlie Sharpsteen * Category: logging * Target version: * Affected Puppet version: development * Keywords: error cert generate customer * Branch: ## Overview ## Running puppet cert in 2.6.next f135a64 performs the desired certificate generation, but displays a nasty error message int he process. ## Steps to reproduce ## $ puppet cert --confdir ~/.puppet/conf_enc --generate foo.bar.baz --certdnsnames foo:foo.bar.baz:puppet notice: foo.bar.baz has a waiting certificate request notice: Signed certificate request for foo.bar.baz notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/ca/requests/foo.bar.baz.pem' notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/certificate_requests/foo.bar.baz.pem' err: Could not call generate: Could not find certificate request for foo.bar.baz $ echo $? 0 $ puppet cert --print foo.bar.baz (Works as expected, certificate was generated and signed) ## Expected Behavior ## The error shouldn't be displayed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #14652] Resource requiring self fails to apply but does not generate an error, even with --debug
Issue #14652 has been updated by Charlie Sharpsteen.
Assignee set to Charlie Sharpsteen
Bug #14652: Resource requiring self fails to apply but does not generate an
error, even with --debug
https://projects.puppetlabs.com/issues/14652#change-91311
* Author: David Gwilliam
* Status: Needs Decision
* Priority: Normal
* Assignee: Charlie Sharpsteen
* Category: dependency graph
* Target version:
* Affected Puppet version: 2.7.12
* Keywords: customer
* Branch:
class test {
file { '/tmp/file1.txt':
ensure = present,
require = File['/tmp/file1.txt'],
}
file { '/tmp/file2.txt':
ensure = present,
require = File['/tmp/file1.txt'],
}
}
The above code generates an obvious cyclical dependency, but does not return an
error on `puppet agent -t --debug`, though the following is seen:
debug: /Stage[main]/Test/File[/tmp/file1.txt]/require: requires
File[/tmp/file1.txt]
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #19708] puppet agent retry failed http requests
Issue #19708 has been updated by Charlie Sharpsteen. Assignee set to Charlie Sharpsteen Feature #19708: puppet agent retry failed http requests https://projects.puppetlabs.com/issues/19708#change-91312 * Author: Patrick Hemmer * Status: Unreviewed * Priority: Low * Assignee: Charlie Sharpsteen * Category: * Target version: * Affected Puppet version: 3.1.0 * Keywords: customer * Branch: It would be nice if puppet agent had the ability had the ability to retry failed http requests to the puppet master. I have multiple puppet masters sitting behind a load balancer in AWS (ELB). Whenever we update a puppet master, the node is removed from the load balancer while the update occurs. Unfortunately the AWS ELB does not allow quiescent removal of nodes (such that existing connections are allowed to close gracefully). Instead it just severs the connections immediately. This causes errors for agents which are in the middle of making requests to that master. Another related scenario is when you're updating multiple puppet masters. The masters might be in the middle of updating, and so some masters have newer code than the others. A puppet agent gets a catalog from one master, which says a certain file should exist, but then when the agent goes to fetch that file, it fails because the master it tried to fetch from hasn't updated. Retrying wouldn't be an ideal solution for this scenario as a retry could just hit that same out-of-date master again, but it could possibly work. Yes the ideal solution here is session persistence, but the AWS ELB does not support it. It might be useful to even allow a configurable backoff (failure; sleep 2; failure; sleep 5; failure; abort...), though a single retry would be sufficient for the first scenario indicated above. If a backoff is implemented, I think it should only be done once in the whole puppet run. So that if you have a 100 different http requests that have to be made to the puppet master, you don't do the backoff wait thing 100+ times. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #1581] Ability to purge .ssh/authorized_keys
Issue #1581 has been updated by Dolf Schimmel.
Is there any suggested workaround? Right now there only seems to be a way to
add keys to the authorized_keys file, but not to revoke any. Not wanting to put
too fine a point on it, but if I tell my boss he won't like it ;)
Feature #1581: Ability to purge .ssh/authorized_keys
https://projects.puppetlabs.com/issues/1581#change-91318
* Author: Lars Volker
* Status: Accepted
* Priority: Normal
* Assignee: eric sorenson
* Category: ssh
* Target version:
* Affected Puppet version: 0.24.4
* Keywords:
* Branch:
As I'm new to puppet i'll try to describe this as good as i can.
I wanted to use the ssh_authorized_key type to add keys to ssh. After a
discussion on irc i was suggested to use virtual resources and realize each key
for each class needed. This worked well for me.
However i am not able to purge all other keys from the authorized_keys file
without either specifying the comment or by copying an empty file there before
adding the keys, which causes the system to lock up until the update is done.
I tried using resources{} type, but as ssh_authorized_key doesn't support
self.instances this was also of no success.
The feature i'd like to have is an implementation of instances so resources{}
works for authorized_keys.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #3537] It should be possible to trigger (exec) resources with require
Issue #3537 has been updated by eric sorenson.
Let me rephrase Alan's #note-11 because it is a useful point of discussion but
has an error in the code
pre
exec { A:
command = A.command,
onlyif = A.onlyif,
require = Exec[B],
}
exec { B:
command = B.command,
refreshonly = true,
}
/pre
the current behaviour is:
pre
run A.onlyif;
if A.onlyif was sucessful {
run A.command
run B.command
}
/pre
I believe that Kjetil wants a way to express the following behaviour:
pre
run A.onlyif;
if A.onlyif was sucessful {
run B.command;
run A.command;
}
/pre
But to do that means we'd have to pause evaluating resource A, go to B, then
come back to A. A much simpler way to model this would be not to use the
`onlyif` at all but instead make its command a top-level exec resource too. It
will be run every time either way so there's no performance hit, and the
savings in complexity seems quite worthwhile. So you'd have
pre
exec { prereq:
command = formerly A.onlyif
notify = Exec[B]
}
exec { A:
command = A.command,
refreshonly = true,
}
exec { B:
command = B.command,
refreshonly = true,
notify = Exec[A]
}
pre
Which, as far as I can tell, gets you to exactly the same state without weird
runarounds.
More on the apt-get situation in a moment.
Feature #3537: It should be possible to trigger (exec) resources with require
https://projects.puppetlabs.com/issues/3537#change-91319
* Author: Kjetil Torgrim Homme
* Status: Needs Decision
* Priority: Normal
* Assignee: eric sorenson
* Category: metaparameters
* Target version:
* Affected Puppet version: 0.25.4
* Keywords:
* Branch:
When an Exec has conditions associated with it (unless, creates, onlyif), it
can be useful to be state prerequisites which are only run when the exec itself
is run.
Consider this simple example::
pre
exec { prereq:
command = /bin/echo prereq,
refreshonly = true
}
exec { main:
command = /bin/echo main,
onlyif = /bin/grep foobar /etc/issue,
require = Exec[prereq]
}
/pre
Here, the refreshonly will cause prereq to never run, since a require isn't
enough to trigger it. Without refreshonly, it will run every time, but the
desired behaviour is that prereq is run iff the onlyif command succeeds.
Obviously the behaviour of refreshonly = true can't change, and I can't
think of a good name for a tri-state alternative -- refreshonly =
'requires-too' ? allevents may be more workable.
My prefered solution would be a new parameter requireonly. Perhaps slightly
misleading name, since before should trigger execution, too, but I think most
people will understand that require/before are inherently intertwined. This
could later be generalised into a metaparameter to work for more types, e.g.
you could have a parent File which is only checked/updated/created when some
other File requires 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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #16871] gem package provider should reset permissions
Issue #16871 has been updated by Joseph Mulloy. Can there be a parameter to set a particular umask? Without the ability to override the umask the gems provider is practically useless. This makes it very difficult for me to use Puppet to bootstrap the install of the master since gems installs with a restrictive umask, which is ridiculous for a system wide gem install. We need a solution. Bug #16871: gem package provider should reset permissions https://projects.puppetlabs.com/issues/16871#change-91322 * Author: Tails developers * Status: Rejected * Priority: Normal * Assignee: * Category: provider * Target version: * Affected Puppet version: * Keywords: * Branch: If the user running `puppet apply` uses a restrictive umask (e.g. 0077), gems installed using the gem package provider will be unreadable for all users except root. rubygems author has [ruled this behaviour as a feature](https://github.com/rubygems/rubygems/issues/272), but in Puppet context I fail to see a reason why the gem package provider should behave differently than, for example, apt. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #6112] (Investigating) Puppet cert generate error message when it succeeds
Issue #6112 has been updated by Charlie Sharpsteen. Status changed from Needs More Information to Investigating I suspect what is going on here is that the certificate request is being auto-signed during generation. Then, `puppet cert` makes an attempt to explicitly sign the request but fails. Will look into this. Bug #6112: Puppet cert generate error message when it succeeds https://projects.puppetlabs.com/issues/6112#change-91326 * Author: Jeff McCune * Status: Investigating * Priority: Normal * Assignee: Charlie Sharpsteen * Category: logging * Target version: * Affected Puppet version: development * Keywords: error cert generate customer * Branch: ## Overview ## Running puppet cert in 2.6.next f135a64 performs the desired certificate generation, but displays a nasty error message int he process. ## Steps to reproduce ## $ puppet cert --confdir ~/.puppet/conf_enc --generate foo.bar.baz --certdnsnames foo:foo.bar.baz:puppet notice: foo.bar.baz has a waiting certificate request notice: Signed certificate request for foo.bar.baz notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/ca/requests/foo.bar.baz.pem' notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/certificate_requests/foo.bar.baz.pem' err: Could not call generate: Could not find certificate request for foo.bar.baz $ echo $? 0 $ puppet cert --print foo.bar.baz (Works as expected, certificate was generated and signed) ## Expected Behavior ## The error shouldn't be displayed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Feature #3537] It should be possible to trigger (exec) resources with require
Issue #3537 has been updated by eric sorenson.
Sorry for a lack of updates. This is one that nigel transferred over to me when
I started and it was lost in a flood of other similar transfers so I didn't
know I was on the hook for it. Thanks Nigel!! :-D
The specific problem of running `apt-get update` before installing a package --
The requirement from Micah at [note 14](#note-14) might not be feasible:
I’m not sure what this solves except to make it so the exec is only run at
certain intervals, which is what cron-apt does. What we want puppet to do is
to run an apt-get update before a package is installed, not at random times,
and not at every run.
The problem with this is that it would work for install but not for updates.
apt would never know, due to the infinite lifetime of downloaded metadata, that
there were upgrades available. So if there was a new metaparameter, or if the
provider were twiddled to do apt-get update inside itself only if the ensure
were found to be out of sync (as someone here proposed), it'd have to build
logic to satisfy ANY of the following conditions:
1. if any package is specified to be present and isn't, then apt-get update
2. if any package is specified to be a particular version and there's an older
installed version, then apt-get update
3. if any package is specified to be ensure=latest, then apt-get update
It's that last one that gets me. Some questions for the watchers:
* are you (micah, alex hewson, etc) specifying every version for every package?
* Do you do `ensure=latest` anywhere?
* There are a couple of comments about the load on mirrors; is it really that
bad? (Not snark, I honestly don't know, I come from a redhat background and
have had thousands of servers hitting metadata on repository servers at 30
minute intervals without negative affect, but that is only 3 files with
if-modified-since headers so perhaps its much worse on apt servers)
Feature #3537: It should be possible to trigger (exec) resources with require
https://projects.puppetlabs.com/issues/3537#change-91327
* Author: Kjetil Torgrim Homme
* Status: Needs Decision
* Priority: Normal
* Assignee: eric sorenson
* Category: metaparameters
* Target version:
* Affected Puppet version: 0.25.4
* Keywords:
* Branch:
When an Exec has conditions associated with it (unless, creates, onlyif), it
can be useful to be state prerequisites which are only run when the exec itself
is run.
Consider this simple example::
pre
exec { prereq:
command = /bin/echo prereq,
refreshonly = true
}
exec { main:
command = /bin/echo main,
onlyif = /bin/grep foobar /etc/issue,
require = Exec[prereq]
}
/pre
Here, the refreshonly will cause prereq to never run, since a require isn't
enough to trigger it. Without refreshonly, it will run every time, but the
desired behaviour is that prereq is run iff the onlyif command succeeds.
Obviously the behaviour of refreshonly = true can't change, and I can't
think of a good name for a tri-state alternative -- refreshonly =
'requires-too' ? allevents may be more workable.
My prefered solution would be a new parameter requireonly. Perhaps slightly
misleading name, since before should trigger execution, too, but I think most
people will understand that require/before are inherently intertwined. This
could later be generalised into a metaparameter to work for more types, e.g.
you could have a parent File which is only checked/updated/created when some
other File requires 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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #6112] (Accepted) Puppet cert generate error message when it succeeds
Issue #6112 has been updated by Charlie Sharpsteen. Category changed from logging to SSL Status changed from Investigating to Accepted Assignee deleted (Charlie Sharpsteen) Keywords changed from error cert generate customer to error cert_generate autosign customer Autosigning is a very likely culprit: pre [root@puppetmaster ~]# rm -rf /var/lib/puppet/ssl [root@puppetmaster ~]# puppet cert generate puppetagent.boxnet Notice: Signed certificate request for ca Notice: Rebuilding inventory file Notice: puppetagent.boxnet has a waiting certificate request Notice: Signed certificate request for puppetagent.boxnet Notice: Removing file Puppet::SSL::CertificateRequest puppetagent.boxnet at '/var/lib/puppet/ssl/ca/requests/puppetagent.boxnet.pem' Notice: Removing file Puppet::SSL::CertificateRequest puppetagent.boxnet at '/var/lib/puppet/ssl/certificate_requests/puppetagent.boxnet.pem' [root@puppetmaster ~]# puppet cert clean puppetagent.boxnet Notice: Revoked certificate with serial 2 Notice: Removing file Puppet::SSL::Certificate puppetagent.boxnet at '/var/lib/puppet/ssl/ca/signed/puppetagent.boxnet.pem' Notice: Removing file Puppet::SSL::Certificate puppetagent.boxnet at '/var/lib/puppet/ssl/certs/puppetagent.boxnet.pem' Notice: Removing file Puppet::SSL::Key puppetagent.boxnet at '/var/lib/puppet/ssl/private_keys/puppetagent.boxnet.pem' [root@puppetmaster ~]# echo 'puppetagent.boxnet' /etc/puppet/autosign.conf [root@puppetmaster ~]# puppet cert generate puppetagent.boxnet Notice: puppetagent.boxnet has a waiting certificate request Notice: Signed certificate request for puppetagent.boxnet Notice: Removing file Puppet::SSL::CertificateRequest puppetagent.boxnet at '/var/lib/puppet/ssl/ca/requests/puppetagent.boxnet.pem' Notice: Removing file Puppet::SSL::CertificateRequest puppetagent.boxnet at '/var/lib/puppet/ssl/certificate_requests/puppetagent.boxnet.pem' Error: Could not find certificate request for puppetagent.boxnet /pre When using `puppet cert generate`, Puppet first [generates a certificate request](https://github.com/puppetlabs/puppet/blob/3.1.1/lib/puppet/ssl/certificate_authority.rb#L139) and then [signs it](https://github.com/puppetlabs/puppet/blob/3.1.1/lib/puppet/ssl/certificate_authority.rb#L140). During the generation step, the save method of the CertificateRequest class is called which [triggers autosigning](https://github.com/puppetlabs/puppet/blob/3.1.1/lib/puppet/ssl/certificate_request.rb#L12-L19). To summarize: * Certificate generation should take auto signing into account. * It appears autosigning doesn't consult the dns_alt_names parameter. * We should probably log an info or debug message whenever a cert is autosigned so this behavior is easier to detect in the future. Bug #6112: Puppet cert generate error message when it succeeds https://projects.puppetlabs.com/issues/6112#change-91329 * Author: Jeff McCune * Status: Accepted * Priority: Normal * Assignee: * Category: SSL * Target version: * Affected Puppet version: development * Keywords: error cert_generate autosign customer * Branch: ## Overview ## Running puppet cert in 2.6.next f135a64 performs the desired certificate generation, but displays a nasty error message int he process. ## Steps to reproduce ## $ puppet cert --confdir ~/.puppet/conf_enc --generate foo.bar.baz --certdnsnames foo:foo.bar.baz:puppet notice: foo.bar.baz has a waiting certificate request notice: Signed certificate request for foo.bar.baz notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/ca/requests/foo.bar.baz.pem' notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/certificate_requests/foo.bar.baz.pem' err: Could not call generate: Could not find certificate request for foo.bar.baz $ echo $? 0 $ puppet cert --print foo.bar.baz (Works as expected, certificate was generated and signed) ## Expected Behavior ## The error shouldn't be displayed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #6112] Puppet cert generate doesn't play nice with autosigning
Issue #6112 has been updated by Charlie Sharpsteen. Subject changed from Puppet cert generate error message when it succeeds to Puppet cert generate doesn't play nice with autosigning Bug #6112: Puppet cert generate doesn't play nice with autosigning https://projects.puppetlabs.com/issues/6112#change-91330 * Author: Jeff McCune * Status: Accepted * Priority: Normal * Assignee: * Category: SSL * Target version: * Affected Puppet version: development * Keywords: error cert_generate autosign customer * Branch: ## Overview ## Running puppet cert in 2.6.next f135a64 performs the desired certificate generation, but displays a nasty error message int he process. ## Steps to reproduce ## $ puppet cert --confdir ~/.puppet/conf_enc --generate foo.bar.baz --certdnsnames foo:foo.bar.baz:puppet notice: foo.bar.baz has a waiting certificate request notice: Signed certificate request for foo.bar.baz notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/ca/requests/foo.bar.baz.pem' notice: Removing file Puppet::SSL::CertificateRequest foo.bar.baz at '/Users/jeff/.puppet/var/ssl/certificate_requests/foo.bar.baz.pem' err: Could not call generate: Could not find certificate request for foo.bar.baz $ echo $? 0 $ puppet cert --print foo.bar.baz (Works as expected, certificate was generated and signed) ## Expected Behavior ## The error shouldn't be displayed. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet - Bug #20813] Defined type with recursion fails with duplicate declaration
Issue #20813 has been updated by Igor Muratov.
Sorry, I have to explain how to reproduce the output:
pre
Mogul:manifest user$ puppet minicat compile --config /etc/puppet/puppet.conf
--modulepath=~/Dvl/my_test/modules --node_terminus=exec --classlist
filesystem::common --node example.com
notice: looking up example.com...
err: Duplicate declaration: Filesystem::Make_dir[/usr/local] is already
declared in file /home/user/Dvl/my_test/modules/filesystem/manifests/init.pp at
line 63; cannot redeclare at
/home/user/Dvl/my_test/modules/filesystem/manifests/init.pp:63 on node
example.com
err: Try 'puppet help minicat compile' for usage
There is no issue with /usr but with the longest common part of items. The
workaround is to add the parent directory into the list like that:
/usr/local
/usr/local/bin
/usr/local/etc
/pre
Bug #20813: Defined type with recursion fails with duplicate declaration
https://projects.puppetlabs.com/issues/20813#change-91331
* Author: Igor Muratov
* Status: Unreviewed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* Affected Puppet version: 2.7.21
* Keywords: defined types, recursion, mkdir_p
* Branch:
First of all let me say it fails in some situations, not always. Here is the
code which I have:
pre
class filesystem {
File {
ensure = directory,
mode= '0755',
owner = 'root',
group = 'root',
}
# Recursive function creates chain of objects
define make_dir($owner=undef, $group=undef, $mode=undef) {
file { $name:
ensure = directory,
mode= $mode,
owner = $owner,
group = $group,
}
# Take parent directory name
$parent = regsubst($name, '(.+)(/[^/]+)$', '\1')
# Recursive call if object does not exist
if ( $parent != and ! defined(File[$parent])) {
make_dir { $parent:
mode = $mode,
owner = $owner,
group = $group,
}
File[$parent] - File[$name]
}
}
}
class filesystem::common inherits filesystem {
make_dir { [
'/usr/local/bin',
'/usr/local/etc',
]:
}
}
/pre
So, when I do have two directories with the same parent directory, the class
will fail:
pre
Mogul:manifests user$ minicatv example.com filesystem::common
notice: looking up example.com...
err: Duplicate declaration: Filesystem::Make_dir[/usr/local] is already
declared in file /home/user/Dvl/my_test/modules/filesystem/manifests/init.pp at
line 63; cannot redeclare at
/home/user/Dvl/my_test/modules/filesystem/manifests/init.pp:63 on node
example.com
err: Try 'puppet help minicat compile' for usage
There is no issue with /usr but with the longest common part of items. The
workaround is to add the parent directory into the list like that:
/usr/local
/usr/local/bin
/usr/local/etc
/pre
That case all directory objects, including /usr, will be created with no
errors. It is not obvious to me where and why puppet fails and I only assuming
it could be a bug.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
Puppet Bugs group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
