Jira (PUP-9602) puppet 6 apply fails if puppet types have been generated
Title: Message Title Josh Cooper updated an issue Puppet / PUP-9602 puppet 6 apply fails if puppet types have been generated Change By: Josh Cooper Team: Server Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9602) puppet 6 apply fails if puppet types have been generated
Title: Message Title Josh Cooper updated an issue Puppet / PUP-9602 puppet 6 apply fails if puppet types have been generated Change By: Josh Cooper Sub-team: Language Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9602) puppet 6 apply fails if puppet types have been generated
Title: Message Title
Josh Cooper commented on PUP-9602
Re: puppet 6 apply fails if puppet types have been generated
This must be an edge case as it doesn't have the issue when using the following example: /etc/puppetlabs/code/environments/production/modules/ntp/init.pp
class ntp {
include ntp::service
anchor { 'ntp_first': } -> Class['ntp::service'] -> anchor { 'ntp_last': }
}
/etc/puppetlabs/code/environments/production/modules/ntp/service.pp
class ntp::service {
notify { 'service': }
}
[root@sfofmfwbut1qvgr modules]# puppet apply -e "include ntp"
Warning: METAMANAGER LOADED file
Jira (PUP-9594) Prepare release announcement (Puppet Platform 5.5.13)
Title: Message Title Bill Tang commented on PUP-9594 Re: Prepare release announcement (Puppet Platform 5.5.13) Combined announcement with 6.0.8: Please see https://tickets.puppetlabs.com/browse/PUP-9610 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9602) puppet 6 apply fails if puppet types have been generated
Title: Message Title Josh Cooper commented on PUP-9602 Re: puppet 6 apply fails if puppet types have been generated Thanks for the repro steps Vadym Chepkov. I was able to reproduce this in 6.4.0. The issue seems as we expected. The pops loaders load the pcore model to compile the catalog. For reasons unknown, when converting to a RAL catalog, the metatype manager is called to (re)load types that it already knows about: [root@sfofmfwbut1qvgr modules]# puppet apply -e 'include puppetdb::database::postgresql' Warning: METAMANAGER LOADED file Warning: METAMANAGER LOADED user Warning: METAMANAGER LOADED group Warning: METAMANAGER LOADED stage Warning: METAMANAGER LOADED whit Warning: METAMANAGER LOADED component Warning: METAMANAGER LOADED package Warning: METAMANAGER LOADED service Warning: METAMANAGER LOADED yumrepo Warning: METAMANAGER LOADED exec Warning: POPS LOADED resource http://puppet.com/2016.1/runtime/resource_type_pp/postgresql_psql from pcore model
Jira (PUP-9610) Prepare release announcement (Puppet Platform 6.0.8)
Title: Message Title Bill Tang commented on PUP-9610 Re: Prepare release announcement (Puppet Platform 6.0.8) Draft announcement for review - Nirupama Mantha, Jean Bond, Heston Hoffman Puppet Platform 5.5.13 and 6.0.8 are now available! We’re happy to announce the next set of release for the Puppet 5.5 (LTS series) and Puppet 6.0 (Feature series) are now available. These releases contain bug fixes and performance improvements, notably: Improved debug logging to specify where server setting originates (server or server_list) Note that Agent support has been removed for Cumulus 2.2 (amd64) and Debian 7 (x86_64, i386) as part of this release. You can see the full list of changes in the release notes: For Puppet 5.5.13: https://puppet.com/docs/puppet/5.5/release_notes.html For Puppet 6.0.8: https://puppet.com/docs/puppet/6.0/release_notes_osp.html Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9630) Prepare release announcement (Puppet Platform 6.4.1)
Title: Message Title Bill Tang commented on PUP-9630 Re: Prepare release announcement (Puppet Platform 6.4.1) Draft announcement - Nirupama Mantha, Jean Bond, Heston Hoffman The next monthly release in Puppet 6 series is now available. Puppet Platform 6.4.1 includes improvements, bug fixes, and feature updates to Puppet Server and Puppet Agent. Performance improvement for Puppet Device plugin sync Improved debug logging to specify where server setting originates (server or server_list) Note that Puppet agent support has been removed for Cumulus 2.2 (amd64) and Debian 7 (x86_64, i386) as part of this release. View the full release notes and installation information: https://puppet.com/docs/puppet/6.4/puppet_index.html Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1914) Expose Facter.reset under jruby
Title: Message Title Jean Bond updated an issue Facter / FACT-1914 Expose Facter.reset under jruby Change By: Jean Bond Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1906) networking.dhcp fact is blank on RedHat 8 beta
Title: Message Title Jean Bond updated an issue Facter / FACT-1906 networking.dhcp fact is blank on RedHat 8 beta Change By: Jean Bond Labels: dhcp known-issue-added linux redhat resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-901) Improve Plan Logging with apply
Title: Message Title
Nick Lewis updated an issue
Puppet Task Runner / BOLT-901
Improve Plan Logging with apply
Change By:
Nick Lewis
Problem I want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.Refactor logging and outputting * All actions (plan start/finish, step start/finish, node start/result) are handed to the outputter as an event stream. * {{--verbose}} becomes an option for the outputter not the logger. * "verbose" is now defined to mean node-level results are included in the output when using the human format. "verbose" has no meaning for the JSON format. * Plans default to non-verbose, everything else defaults to verbose. {{--no-verbose}} is accepted as an addition to {{--verbose}} * "plan logging" becomes an outputter concept, rather than an executor concept * {{without_default_logging}} becomes state tracked on the outputter that causes it to simply ignore action events.Human outputter * Human outputter without verbose prints starting action and summary for action messages. * Human outputter prints full node-level result with {{--verbose}} * For {{bolt apply}} _without_ verbose, human outputter only prints a summary of the run * For {{bolt apply}} _with_ verbose, human outputter prints logs from each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet". * All output from this outputter can go to stdout (currently messages go to stderr for plans)JSON outputter: * When in non-plan mode behaves as it does currently. * Logs entire JSON format of {{apply}} result on stderr for each node at {{--verbose}} * This outputter can show intermediate results on stderr in human format, but doesn't have to for this ticketLog output: * The default console log level is now "warn". No "human-oriented" output should come from the logger except for warnings and errors. * Log files still default to "info". * {{ \ - \ -debug - }} still sets debug level for console logger, {{-verbose}} does not affect the logger at all * A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the loggerPuppet log functions: * Eventually these should be handled by the outputter rather than the logger directly, but this is left to a later ticket.apply_prep/get_resources: * These probably need to have specific events the outputter can handle. That is out of scope for this ticket. For now just rely on {{without_default_logging}}
Jira (BOLT-901) Improve Plan Logging with apply
Title: Message Title
Nick Lewis updated an issue
Puppet Task Runner / BOLT-901
Improve Plan Logging with apply
Change By:
Nick Lewis
Problem I want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.Refactor logging and outputting * All actions (plan start/finish, step start/finish, node start/result) are handed to the outputter as an event stream. * {{--verbose}} becomes an option for the outputter not the logger. * "verbose" is now defined to mean node-level results are included in the output when using the human format. "verbose" has no meaning for the JSON format. * Plans default to non-verbose, everything else defaults to verbose. {{--no-verbose}} is accepted as an addition to {{--verbose}} * "plan logging" becomes an outputter concept, rather than an executor concept * {{without_default_logging}} becomes state tracked on the outputter that causes it to simply ignore action events.Human outputter * Human outputter without verbose prints starting action and summary for action messages. * Human outputter prints full node-level result with {{--verbose}} * For {{bolt apply}} _without_ verbose, human outputter only prints a summary of the run * For {{bolt apply}} _with_ verbose, human outputter prints logs from each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet". * All output from this outputter can go to stdout (currently messages go to stderr for plans)JSON outputter: * When in non-plan mode behaves as it does currently. * Logs entire JSON format of {{apply}} result on stderr for each node at {{--verbose}} * This outputter can show intermediate results on stderr in human format, but doesn't have to for this ticketLog output: * The default console log level is now "warn". No "human-oriented" output should come from the logger except for warnings and errors. * Log files still default to "info". * {{\-\-debug}} still sets debug level for console logger, {{ \ - \- verbose}} does not affect the logger at all * A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the loggerPuppet log functions: * Eventually these should be handled by the outputter rather than the logger directly, but this is left to a later ticket.apply_prep/get_resources: * These probably need to have specific events the outputter can handle. That is out of scope for this ticket. For now just rely on {{without_default_logging}}
Jira (BOLT-901) Improve Plan Logging with apply
Title: Message Title
Nick Lewis updated an issue
Puppet Task Runner / BOLT-901
Improve Plan Logging with apply
Change By:
Nick Lewis
ProblemI want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.Refactor logging and outputting * All actions (plan start/finish, step start/finish, node start/result) are handed to the outputter as an event stream.* {{--verbose}} becomes an option for the outputter not the logger.* "verbose" is now defined to mean node-level results are included in the output when using the human format. "verbose" has no meaning for the JSON format.* Plans default to non-verbose, everything else defaults to verbose. {{ \ - \ -no \ -verbose}} is accepted as an addition to {{--verbose}}* "plan logging" becomes an outputter concept, rather than an executor concept , used by the json outputter initially * {{without_default_logging}} becomes state tracked on the outputter that causes it to simply ignore action events.Human outputter* Human outputter without verbose prints starting action and summary for action messages.* Human outputter prints full node-level result with {{--verbose}}* For {{bolt apply}} _without_ verbose, human outputter only prints a summary of the run* For {{bolt apply}} _with_ verbose, human outputter prints logs from each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet".* All output from this outputter can go to stdout (currently messages go to stderr for plans)JSON outputter:* When in non-plan mode behaves as it does currently.* Logs entire JSON format of {{apply}} result on stderr for each node at {{--verbose}}* This outputter can show intermediate results on stderr in human format, but doesn't have to for this ticketLog output:* The default console log level is now "warn". No "human-oriented" output should come from the logger except for warnings and errors.* Log files still default to "info".* {{--debug - }} still sets debug level for console logger, {{- - verbose}} does not affect the logger at all* A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the loggerPuppet log functions:* Eventually these should be handled by the outputter rather than the logger directly, but this is left to a later ticket.apply_prep/get_resources:* These probably need to have specific events the outputter can handle. That is out of scope for this ticket. For now just rely on {{without_default_logging}}
Jira (BOLT-901) Improve Plan Logging with apply
Title: Message Title
Nick Lewis updated an issue
Puppet Task Runner / BOLT-901
Improve Plan Logging with apply
Change By:
Nick Lewis
ProblemI want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.Refactor logging and outputting* All actions (plan start/finish, step start/finish, node start/result) are handed to the outputter as an event stream.* {{--verbose}} becomes an option for the outputter not the logger.* "verbose" is now defined to mean node-level results are included in the output when using the human format. "verbose" has no meaning for the JSON format.* Plans default to non-verbose, everything else defaults to verbose. {{ \ - \ -no \ -verbose}} is accepted as an addition to {{--verbose}}* "plan logging" becomes an outputter concept, rather than an executor concept, used by the json outputter initially* {{without_default_logging}} becomes state tracked on the outputter that causes it to simply ignore action events.Human outputter* Human outputter without verbose prints starting action and summary for action messages.* Human outputter prints full node-level result with {{--verbose}}* For {{bolt apply}} _without_ verbose, human outputter only prints a summary of the run* For {{bolt apply}} _with_ verbose, human outputter prints logs from each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet".* All output from this outputter can go to stdout (currently messages go to stderr for plans)JSON outputter:* When in non-plan mode behaves as it does currently.* Logs entire JSON format of {{apply}} result on stderr for each node at {{--verbose}}* This outputter can show intermediate results on stderr in human format, but doesn't have to for this ticketLog output:* The default console log level is now "warn". No "human-oriented" output should come from the logger except for warnings and errors.* Log files still default to "info".* {{--debug}} still sets debug level for console logger, {{--verbose}} does not affect the logger at all* A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the loggerPuppet log functions:* Eventually these should be handled by the outputter rather than the logger directly, but this is left to a later ticket.apply_prep/get_resources:* These probably need to have specific events the outputter can handle. That is out of scope for this ticket. For now just rely on {{without_default_logging}}
Jira (BOLT-901) Improve Plan Logging with apply
Title: Message Title
Alex Dreyer updated an issue
Puppet Task Runner / BOLT-901
Improve Plan Logging with apply
Change By:
Alex Dreyer
ProblemI want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.Refactor logging and outputting* All actions (plan start/finish, step start/finish, node start/result) are handed to the outputter as an event stream.* {{--verbose}} becomes an option for the outputter not the logger.* "verbose" is now defined to mean node-level results are included in the output when using the human format. "verbose" has no meaning for the JSON format.* Plans default to _non_ non -verbose, everything else defaults to verbose. {{--no-verbose}} is accepted as an addition to {{--verbose}}* "plan logging" becomes an outputter concept, rather than an executor concept, used by the json outputter initially* {{without_default_logging}} becomes state tracked on the outputter that causes it to simply ignore action events.Human outputter* Human outputter without verbose prints starting action and summary for action messages.* Human outputter prints full node-level result with {{--verbose}}* For {{bolt apply}} _without_ verbose, human outputter only prints a summary of the run* For {{bolt apply}} _with_ verbose, human outputter prints logs from each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet".* All output from this outputter can go to stdout (currently messages go to stderr for plans)JSON outputter:* When in non-plan mode behaves as it does currently.* Logs entire JSON format of {{apply}} result on stderr for each node at {{--verbose}}* This outputter can show intermediate results on stderr in human format, but doesn't have to for this ticketLog output:* The default console log level is now "warn". No "human-oriented" output should come from the logger except for warnings and errors.* Log files still default to "info".* {{--debug}} still sets debug level for console logger, {{--verbose}} does not affect the logger at all* A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the loggerPuppet log functions:* Eventually these should be handled by the outputter rather than the logger directly, but this is left to a later ticket.apply_prep/get_resources:* These probably need to have specific events the outputter can handle. That is out of scope for this ticket. For now just rely on {{without_default_logging}}
Jira (PUP-9645) User Rights Management SIP issue on MacOS 10.14.x
Title: Message Title
Josh Cooper updated an issue
Puppet / PUP-9645
User Rights Management SIP issue on MacOS 10.14.x
Change By:
Josh Cooper
*Puppet Version: 6.4.0* *Puppet Server Version: 6.3.0* *OS Name/Version: MacOS 10.14.3*Since moving to Mojave I have been unable to run puppet agent --test without first booting into Recovery Mode and disabling SIP with 'csrutil disable'. I then boot normally and run puppet to configure my Macs, then boot back into Recovery Mode to reenable SIP. I suspect it's a result of this issue. Below is the output that I get when I attempt to run puppet with SIP enabled on a 10.14.3 system: {noformat} FVF23JIL23KD:~ jdoe$ sudo /opt/puppetlabs/puppet/bin/puppet agent --test Password: Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Info: Caching catalog for fvf23jil23kd.company.com Info: Applying configuration version 'puppet-production-50e48363285' Notice: Hiera returned role: mac_laptop Notice: /Stage[main]/Main/Notify[Hiera returned role: mac_laptop]/message: defined 'message' as 'Hiera returned role: mac_laptop' Error: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: /Stage[main]/company_mac::Config/User[company_admin]/password: change from [redacted] to [redacted] failed: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: /Stage[main]/company_mac::Config/User[company_admin]/salt: change from '2922d494d507d8228f83cd286788b3bd188bebb507c911424332ae9031a7e804' to '40cb359a1408e382fd1198f86eaa7d3b1ccdb522f105662c0afd916c576872c9' failed: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/laptop_admin.plist Error: /Stage[main]/company_mac::Config/User[company_admin]/iterations: change from 74626 to 28328 failed: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Notice: /Stage[main]/company_mac::Config/File[/var/company_admin]: Dependency User[company_admin] has failures: true Warning: /Stage[main]/company_mac::Config/File[/var/company_admin]: Skipping because of failed dependencies Info: Stage[main]: Unscheduling all events on Stage[main] Notice: Applied catalog in 13.34 seconds {noformat} Puppet appears unable to manage user rights with SIP enabled. *Desired Behavior:*Puppet client could manage user rights without needing to disable SIP. *Actual Behavior:*(attached)
Jira (BOLT-901) Improve Plan Logging with apply
Title: Message Title
Nick Lewis updated an issue
Puppet Task Runner / BOLT-901
Improve Plan Logging with apply
Change By:
Nick Lewis
ProblemI want useful human readable output showing the events from each targets apply during a plan. This is especially useful when debugging an apply statement in a plan.Refactor logging and outputting* All actions and plan output function ( notice plan start / warm finish, step start / etc finish, node start/result ) are handed to the outputter as an event stream .* {{--verbose}} becomes an option for the outputter not the logger.* By default " single actions verbose " {{bolt command run}} ({{bolt task run}} as opposed is now defined to {{bolt plan run}}) mean node-level results are run verbosely included in the output when using the human format . "verbose" has no meaning for the JSON format.* Plans default to _non_-verbose, everything else defaults to verbose. {{--no-verbose}} is accepted as an option addition to override this behavior. {{--verbose}} * "plan logging" becomes and an outputter concept , rather than an executor concept, used by the json outputter initially* {{without_default_logging}} becomes state tracked on the outputter that causes it to simply ignore action events.Human outputter* Human outputter without verbose prints starting action and summary for action messages.* Human outputter prints full node-level result with {{--verbose}}* With For {{bolt apply }} _without_ verbose, human outputter only prints a summary of entire the run without verbose * With For {{ --verbose bolt apply }} apply _with_ verbose, human outputter prints logs from the each report showing at least changes. This is probably notice level messages and above, maybe excluding messages where the source is "Puppet". * All output from this outputter can go to stdout (currently messages go to stderr for plans) JSON outputter:* When in non-plan mode behaves are as it does currently.* When in plan mode logs only the plan Logs entire JSON format of {{apply}} result to stdout. on stderr for each node at {{--verbose}} * When in plan mode and verbose mode sends This outputter can show intermediate results to on stderr in human format, but doesn't have to for this ticketLog output:* The default console log level is now "warn" . (perhaps through No "human-oriented" output should come from the logger except for warnings and errors . notice?) * logs entire jsonformat of apply result on stderr Log files still default to "info".* {{--debug}} still sets debug level for each node at console logger, {{--verbose}} does not affect the logger at all * A "logger outputter" should consume the event stream and translate each event to appropriate log messages that are passed to the logger Puppet log functions:* Eventually these should be handled by the outputter rather then than the logger directly , but this is left to a later ticket.apply_prep/get_resources:* these These probably need to have specific events the outp
Jira (PUP-9645) User Rights Management SIP issue on MacOS 10.14.x
Title: Message Title Josh Cooper updated an issue Puppet / PUP-9645 User Rights Management SIP issue on MacOS 10.14.x Change By: Josh Cooper Team: Puppet Romania Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-4326) PuppetDB rejects catalogs with tags added automatically by Puppet
Title: Message Title Heston Hoffman updated an issue PuppetDB / PDB-4326 PuppetDB rejects catalogs with tags added automatically by Puppet Change By: Heston Hoffman Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-4275) Support import/export of "configure expiration" commands
Title: Message Title Heston Hoffman updated an issue PuppetDB / PDB-4275 Support import/export of "configure expiration" commands Change By: Heston Hoffman Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-4271) Create a new query endpoint/AST entity to query certname lifetime data
Title: Message Title Heston Hoffman updated an issue PuppetDB / PDB-4271 Create a new query endpoint/AST entity to query certname lifetime data Change By: Heston Hoffman Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-4315) Handle resource-event duplicates in reports
Title: Message Title Heston Hoffman updated an issue PuppetDB / PDB-4315 Handle resource-event duplicates in reports Change By: Heston Hoffman Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9643) Issue in protection against illegal methods in legacy functions
Title: Message Title Henrik Lindberg commented on PUP-9643 Re: Issue in protection against illegal methods in legacy functions The function in question is using Ruby syntax that the checker does not understand as valid. The implementation of the get_host_hash() function can be changed to the equivalent and shorter: Puppet::Parser::Functions::newfunction( ... ) I am curious what led the function in question to use the implementation it now has with a reopen of the module Puppet::Parser::Functions to just make a call to a static function in that module. If that is documented somewhere that documentation should change as the construct where the module is reopened creates too many opportunities to screw up the puppet runtime. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bu
Jira (PUP-9643) Issue in protection against illegal methods in legacy functions
Title: Message Title
Josh Cooper commented on PUP-9643
Re: Issue in protection against illegal methods in legacy functions
Having trouble reproducing this as there is a syntax error in the function, which seems to trigger the "does not seem to be a Puppet 3x API function" error:
$ bx puppet apply -e "notice(get_host_hash(1, 2))"
Error: Evaluation Error: Error while evaluating a Function Call, The code loaded from /Users/josh/work/puppet/lib/puppet/parser/functions/get_host_hash.rb does not seem to be a Puppet 3x API function - no 'newfunction' call. (line: 1, column: 8) on node localhost
$ bx puppet apply -e "notice(get_host_hash(1, 2))" --no-func3x_check
Error: Could not run: /Users/josh/work/puppet/lib/puppet/parser/functions/get_host_hash.rb:23: syntax error, unexpected keyword_and
...argnr].start_with?("#") and and not subentry[secondargnr].em...
...^~~
/Users/josh/work/puppet/lib/puppet/parser/functions/get_host_hash.rb:37: syntax error, unexpected keyword_end, expecting end-of-input
There is a double and and in the script. If I delete the extra one, then it works as expected:
$ bx puppet apply -e "notice(get_host_hash(1, 2))"
Notice: Scope(Class[main]): {}
Jira (PUP-9505) Fact yaml should quote mac addresses.
Title: Message Title
Branan Riley commented on PUP-9505
Re: Fact yaml should quote mac addresses.
Some quick poking shows we're properly passing the mac address as a String object to Ruby from CFacter, and that the YAML serialization correctly quotes a string that's possibly parseable as an integer:
irb(main):006:0> Facter.value('macaddress').class
=> String
irb(main):007:0> require 'yaml'
=> true
irb(main):008:0> YAML.dump(Facter.value('macaddress'))
=> "--- d4:81:d7:24:87:6f\n...\n"
irb(main):009:0> YAML.dump("44:49:56")
=> "--- '44:49:56'\n"
This is with Facter 3.11.5 and Ruby 2.4.3 on my laptop. I'm unsure how we're ending up with unquoted values in the YAML output - possibly this is a ruby version issue that causes different behaviors with the output here? This would probably be a Ruby bug, in that case.
Add Commen
Jira (PUP-9505) Fact yaml should quote mac addresses.
Title: Message Title Josh Cooper commented on PUP-9505 Re: Fact yaml should quote mac addresses. Native facter defines macaddress to be a string in its schema, and knows to emit it as a quoted string: [root@ka8y738etxt42jh ~]# facter --version 3.13.1 (commit 4e1df48f76caa0eaeee90af4239a1df450d45cd7) [root@ka8y738etxt42jh ~]# facter -y macaddress macaddress: "00:50:56:9a:8f:a7" But puppet facts --render-as yaml doesn't know about the type information, and emits it in the plain style: [root@ka8y738etxt42jh ~]# puppet --version 6.4.0 [root@ka8y738etxt42jh ~]# puppet facts --render-as yaml | grep macaddress macaddress: 00:50:56:9a:8f:a7 macaddress_ens160: 00:50:56:9a:8f:a7 Since fact types are not sent along with the facts to the puppetserver, I don't know if there's anything that we can do differently? /cc Branan Riley, Henrik Lindberg
Jira (PDB-4345) Add name field to resource_events to avoid further duplication errors
Title: Message Title Robert Roland created an issue PuppetDB / PDB-4345 Add name field to resource_events to avoid further duplication errors Issue Type: Story Assignee: Unassigned Components: PuppetDB Created: 2019/04/15 12:56 PM Priority: Normal Reporter: Robert Roland In PDB-4315, it was identified that PuppetDB should also have a "name" field in the resource_events to further guarantee uniqueness. Add this field in the terminus and the database. Add Comment This message was sent by Atlassia
Jira (PDB-4345) Add name field to resource_events to avoid further duplication errors
Title: Message Title Robert Roland assigned an issue to Robert Roland PuppetDB / PDB-4345 Add name field to resource_events to avoid further duplication errors Change By: Robert Roland Assignee: Robert Roland Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9589) waitforcert not working in 6.4
Title: Message Title Jean Bond updated an issue Puppet / PUP-9589 waitforcert not working in 6.4 Change By: Jean Bond Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9587) Serial execution with puppet device and ciscopuppet fails
Title: Message Title Jean Bond updated an issue Puppet / PUP-9587 Serial execution with puppet device and ciscopuppet fails Change By: Jean Bond Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9584) Puppet Device plugin sync slow
Title: Message Title Jean Bond updated an issue Puppet / PUP-9584 Puppet Device plugin sync slow Change By: Jean Bond Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9579) device application is broken in 6.4
Title: Message Title Jean Bond updated an issue Puppet / PUP-9579 device application is broken in 6.4 Change By: Jean Bond Release Notes Summary: There was a regression in 6.4.0 which prevented the device application from being able to manage network devices. Note: because the user-facing effect is in 6.4.0 and not 6.0.x, I'm only adding a release note in 6.4.1. -Jean Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9579) device application is broken in 6.4
Title: Message Title Jean Bond updated an issue Puppet / PUP-9579 device application is broken in 6.4 Change By: Jean Bond Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9574) allow_duplicate_certs description is misleading
Title: Message Title Jean Bond updated an issue Puppet / PUP-9574 allow_duplicate_certs description is misleading Change By: Jean Bond Labels: resolved-issue-added Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9645) User Rights Management SIP issue on MacOS 10.14.x
Title: Message Title
Marshall Taylor updated an issue
Puppet / PUP-9645
User Rights Management SIP issue on MacOS 10.14.x
Change By:
Marshall Taylor
Summary:
{brief summary of User Rights Management SIP issue } on MacOS 10.14.x
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9645) {brief summary of issue}
Title: Message Title
Marshall Taylor created an issue
Puppet / PUP-9645
{brief summary of issue}
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
puppet_output.txt
Created:
2019/04/15 10:50 AM
Environment:
MacOS 10.14.3 on 2018 MacBook Pro 13" running puppet agent 6.4.0. Server is Ubuntu 18.04 running puppet server 6.3.0
Priority:
Normal
Reporter:
Marshall Taylor
Puppet Version: 6.4.0 Puppet Server Version: 6.3.0 OS Name/Version: MacOS 10.14.3 Since moving to Mojave I have been unable to run puppet agent --test without first booting into Recovery Mode and disabling SIP with 'csrutil disable'. I then boot normally and run puppet to configure my Macs, then boot back into Recovery Mode to reenable SIP. I suspect it's a result of this issue. Below is the output that I get when I attempt to run puppet with SIP enabled on a 10.14.3 system: FVF23JIL23KD:~ jdoe$ sudo /opt/puppetlabs/puppet/bin/puppet agent --test Password: Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Info: Caching catalog for fvf23jil23kd.company.com Info: Applying configuration version 'puppet-production-50e48363285' Notice: Hiera returned role: mac_laptop Notice: /Stage[main]/Main/Notify[Hiera returned role: mac_laptop]/message: defined 'message' as 'Hiera returned role: mac_laptop' Error: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: /Stage[main]/company_mac::Config/User[company_admin]/password: change from [redacted] to [redacted] failed: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: Operation not permitted @ rb_sysopen - /var/db/dslocal/nodes/Default/users/company_admin.plist Error: /Sta
Jira (BOLT-1231) Use targets instead of nodes in v2 inventory
Title: Message Title Alex Dreyer assigned an issue to Alex Dreyer Puppet Task Runner / BOLT-1231 Use targets instead of nodes in v2 inventory Change By: Alex Dreyer Assignee: Alex Dreyer Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PDB-4344) 6.3.1 release notes
Title: Message Title gepetto-bot created an issue PuppetDB / PDB-4344 6.3.1 release notes Issue Type: Bug Assignee: Unassigned Created: 2019/04/15 10:14 AM Priority: Normal Reporter: gepetto-bot Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs.
Jira (PUP-9644) Improve documentation around sensitive data in puppet
Title: Message Title Rob Braden created an issue Puppet / PUP-9644 Improve documentation around sensitive data in puppet Issue Type: Task Assignee: Unassigned Created: 2019/04/15 9:54 AM Priority: Normal Reporter: Rob Braden Currently, the docs don't accurately reflect the behavior of sensitive data in puppet catalogs. We should update the docs to reduce customer surprise. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9644) Improve documentation around sensitive data in puppet
Title: Message Title Rob Braden updated an issue Puppet / PUP-9644 Improve documentation around sensitive data in puppet Change By: Rob Braden Sprint: Coremunity Grooming Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1246) As a end user I expect the Packages for Bolt to be usable within a secure environment with little friction.
Title: Message Title
Michael Smith commented on BOLT-1246
Re: As a end user I expect the Packages for Bolt to be usable within a secure environment with little friction.
I'd honestly recommend our packaging do something like:
rm -r /opt/puppetlabs/bolt/lib/ruby/gems/2.5.0/gems/*/{test,spec,ext,acceptance,integration,examples}
Some gems package a whole lot of unnecessary files. ffi is the worst, but it's not really there fault; the gem compiler leaves all intermediate object files in ext/.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-bugs@googlegroups.com.
Visit this group at https://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1246) As a end user I expect the Packages for Bolt to be usable within a secure environment with little friction.
Title: Message Title Michael Smith commented on BOLT-1246 Re: As a end user I expect the Packages for Bolt to be usable within a secure environment with little friction. Ugh, gems are the worst. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9641) Puppet Master Installation on FIPS enabled RHEL fails for PE 2018.1.7
Title: Message Title Matt Mason updated an issue Puppet / PUP-9641 Puppet Master Installation on FIPS enabled RHEL fails for PE 2018.1.7 Change By: Matt Mason Summary: Puppet Master Installation on FIPS enabled RHEL fails for PE 2018.1.7 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9641) Puppet Master Installation on FIPS enabled RHEL fails
Title: Message Title Matt Mason updated an issue Puppet / PUP-9641 Puppet Master Installation on FIPS enabled RHEL fails Change By: Matt Mason Method Found: Needs Assessment Customer Feedback Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1247) As a end user I would like the debug flag to report when it a invalid task name is used and discarded
Title: Message Title Kevin Reeuwijk commented on BOLT-1247 Re: As a end user I would like the debug flag to report when it a invalid task name is used and discarded The actual tasks might not be invalid, but they may live inside of invalid modules (e.g. modules with invalid names). Such invalid modules should also be reported, since the individual tasks inside of that module will likely not be parsed at all. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1247) As a end user I would like the debug flag to report when it a invalid task name is used and discarded
Title: Message Title Adam Buxton updated an issue Puppet Task Runner / BOLT-1247 As a end user I would like the debug flag to report when it a invalid task name is used and discarded Change By: Adam Buxton `bolt task show -m /path --debug ` silently discards invalid tasks, where the name of the tasks does not match the containing folder name even if the module name in metadata is valid. This may be that `Bolt` ignores folders with `- ` in their name, but it should probably report this as the error if that's the case. it would be better if this was reported in debug mode as it is usually end user error. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google
Jira (BOLT-1247) As a end user I would like the debug flag to report when it a invalid task name is used and discarded
Title: Message Title Adam Buxton created an issue Puppet Task Runner / BOLT-1247 As a end user I would like the debug flag to report when it a invalid task name is used and discarded Issue Type: Improvement Assignee: Unassigned Created: 2019/04/15 7:20 AM Priority: Normal Reporter: Adam Buxton `bolt task show -m /path --debug ` silently discards invalid tasks, where the name of the tasks does not match the containing folder name even if the module name in metadata is valid. it would be better if this was reported in debug mode as it is usually end user error. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9643) Issue in protection against illegal methods in legacy functions
Title: Message Title
Thorsten Schlump updated an issue
Puppet / PUP-9643
Issue in protection against illegal methods in legacy functions
Change By:
Thorsten Schlump
*Puppet Version: 6.4.0* *Puppet Server Version: 6.3.0* *OS Name/Version: CentOS 7.6.1810*After updating our Puppet Server to latest release we received this issue on agents:root@xyz1000 # puppet agent --test --environment=production Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, The code loaded from /etc/puppetlabs/code/environments/production/modules/etchosts/lib/puppet/parser/functions/get_host_hash.rb does not seem to be a Puppet 3x API function - no 'newfunction' call. (file: /etc/puppetlabs/code/environments/production/modules/etchosts/manifests/base/solaris.pp, line: 94, column: 15) on node xyz1000.xyz.de Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping runThe affected function is valid and was accepted valid before (I only replaced "values" by an empty array to reduce complexity: { { noformat} module Puppet::Parser::Functions }} {{ newfunction(:get_host_hash, :type => :rvalue, :doc => "") do |args| }} {{ # start with an empty hash }} {{ temp = Hash.new }} {{ # empty array in this example }} {{ values = Array.new }} {{ # get the first argument number }} {{ firstargnr = args[1].to_i }} {{ # get the first argument number }} {{ secondargnr = args[2].to_i }} {{ # analyze each entry in the values }} {{ values.each do |entry| }} {{ # split the entry array to sub arrays }} {{ subentry = entry.split }} {{ # if first requested element starts with # sign or second requested argument starts with + sign skip this entry }} {{ if not subentry[firstargnr].empty? and not subentry[firstargnr].start_with?("#") and and not subentry[secondargnr].empty? and not subentry[secondargnr].start_with?("+") }} {{ # add to the hash }} {{ temp.merge!( \ {"#{subentry[firstargnr]}" => "# \ {subentry[secondargnr]}"}) }} {{ end }} {{ end }} {{ # return the hash }} {{ temp }} {{ end }} {{ end }} { { noformat } } *Desired Behavior:*Works fine with 6.0.x and 5.5.x.*Actual Behavior:*Use of "func3x_check = false" in puppet.conf to get te catalog creation running again.root@xyz1000 # puppet agent --test --environment=production Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Info: Caching catalog for xyz1000.xyz.de
Jira (PUP-9643) Issue in protection against illegal methods in legacy functions
Title: Message Title
Thorsten Schlump updated an issue
Puppet / PUP-9643
Issue in protection against illegal methods in legacy functions
Change By:
Thorsten Schlump
*Puppet Version: 6.4.0* *Puppet Server Version: 6.3.0* *OS Name/Version: CentOS 7.6.1810*After updating our Puppet Server to latest release we received this issue on agents:root@xyz1000 # puppet agent --test --environment=productionInfo: Using configured environment 'production'Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Retrieving localesInfo: Loading factsError: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, The code loaded from /etc/puppetlabs/code/environments/production/modules/etchosts/lib/puppet/parser/functions/get_host_hash.rb does not seem to be a Puppet 3x API function - no 'newfunction' call. (file: /etc/puppetlabs/code/environments/production/modules/etchosts/manifests/base/solaris.pp, line: 94, column: 15) on node xyz1000.xyz.deWarning: Not using cache on failed catalogError: Could not retrieve catalog; skipping runThe affected function is valid and was accepted valid before (I only replaced "values" by an empty array to reduce complexity: {{ module Puppet::Parser::Functions }} {{ newfunction(:get_host_hash, :type => :rvalue, :doc => "") do |args| }} {{ # start with an empty hash }} {{ temp = Hash.new }} {{ # empty array in this example }} {{ values = Array.new }} {{ # get the first argument number }} {{ firstargnr = args[1].to_i }} {{ # get the first argument number }} {{ secondargnr = args[2].to_i }} {{ # analyze each entry in the values }} {{ values.each do |entry| }} {{ # split the entry array to sub arrays }} {{ subentry = entry.split }} {{ # if first requested element starts with # sign or second requested argument starts with + sign skip this entry }} {{ if not subentry[firstargnr].empty? and not subentry[firstargnr].start_with?("#") and and not subentry[secondargnr].empty? and not subentry[secondargnr].start_with?("+") }} {{ # add to the hash }} {{ temp.merge!(\{"#{subentry[firstargnr]}" => "#\{subentry[secondargnr]}"}) }} {{ end }} {{ end }} {{ # return the hash }} {{ temp }} {{ end }} {{ end }} {{}} *Desired Behavior:*Works fine with 6.0.x and 5.5.x.*Actual Behavior:*Use of "func3x_check = false" in puppet.conf to get te catalog creation running again.root@xyz1000 # puppet agent --test --environment=productionInfo: Using configured environment 'production'Info: Retrieving pluginfactsInfo: Retrieving pluginInfo: Retrieving localesInfo: Loading factsInfo: Caching catalog for xyz1000.xyz.de
Jira (PUP-9643) Issue in protection against illegal methods in legacy functions
Title: Message Title Thorsten Schlump created an issue Puppet / PUP-9643 Issue in protection against illegal methods in legacy functions Issue Type: Bug Affects Versions: PUP 6.4.0, PUP 6.3.0, PUP 6.2.0 Assignee: Henrik Lindberg Components: Functions Created: 2019/04/15 6:50 AM Priority: Normal Reporter: Thorsten Schlump Puppet Version: 6.4.0 Puppet Server Version: 6.3.0 OS Name/Version: CentOS 7.6.1810 After updating our Puppet Server to latest release we received this issue on agents: root@xyz1000 # puppet agent --test --environment=production Info: Using configured environment 'production' Info: Retrieving pluginfacts Info: Retrieving plugin Info: Retrieving locales Info: Loading facts Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Function Call, The code loaded from /etc/puppetlabs/code/environments/production/modules/etchosts/lib/puppet/parser/functions/get_host_hash.rb does not seem to be a Puppet 3x API function - no 'newfunction' call. (file: /etc/puppetlabs/code/environments/production/modules/etchosts/manifests/base/solaris.pp, line: 94, column: 15) on node xyz1000.xyz.de Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run The affected function is valid and was accepted valid before (I only replaced "values" by an empty array to reduce complexity: module Puppet::Parser::Functions newfunction(:get_host_hash, :type => :rvalue, :doc => "") do |args| start with an empty hash temp = Hash.new empty array in this example values = Array.new
Jira (PUP-9641) Puppet Master Installation on FIPS enabled RHEL fails
Title: Message Title
Matt Mason updated an issue
Puppet / PUP-9641
Puppet Master Installation on FIPS enabled RHEL fails
Change By:
Matt Mason
*Puppet Version: 5.5.10* *Puppet Server Version: 2018.1.7* *OS Name/Version: RHEL 7.6*Immediately after a successful installation/upgrade of Puppet 2018.1.7 on a FIPS enabled RHEL7.6 system, running puppet agent -t on the master node fails with the following error:{quote}Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Unable to generate package repository configuration. Platform described by facts['platform_tag'] 'redhatfips-7-x86_64' is not a known master platform. (file: /opt/puppetlabs/puppet/modules/puppet_enterprise/manifests/repo/config.pp, line: 158, column: 9){quote} This issue isn't observed after a successful installation of Puppet 2019.0.1 in the same configuration.*Desired Behavior:*Puppet installation of the LTS branch should not have an issue installing on FIPS enabled systems.*Actual Behavior:*Using 'puppet facts show' on the system in the for two different configurations (2018 and 2019) shows the platform_tag fact to be identical in both configurations when FIPS mode is enabled for the system:"platform_tag": "redhatfips-7-x86_64", When the system is configured with 2018 puppet installed, the fipsmode issue arises while when installed with 2019, the issue does not occur.
Add Comment
This message
Jira (PUP-9641) Puppet Master Installation on FIPS enabled RHEL fails
Title: Message Title
Matt Mason updated an issue
Puppet / PUP-9641
Puppet Master Installation on FIPS enabled RHEL fails
Change By:
Matt Mason
*Puppet Version: 5.5.10* *Puppet Server Version: 2018.1.7* *OS Name/Version: RHEL 7.6*Immediately after a successful installation/upgrade of Puppet 2018.1.7 on a FIPS enabled RHEL7.6 system, running puppet agent -t on the master node fails with the following error:{quote}Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Unable to generate package repository configuration. Platform described by facts['platform_tag'] 'redhatfips-7-x86_64' is not a known master platform. (file: /opt/puppetlabs/puppet/modules/puppet_enterprise/manifests/repo/config.pp, line: 158, column: 9){quote} This issue isn't observed after a successful installation of Puppet 2019.0.1 in the same configuration.*Desired Behavior:*Puppet installation of the LTS branch should not have an issue installing on FIPS enabled systems.*Actual Behavior:*Using Puppet 'puppet facts show ' on the system in the two different configurations (2018 and 2019) shows the platform_tag fact to be identical in both configurations when FIPS mode is enabled for the system:"platform_tag": "redhatfips-7-x86_64",
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PUP-9641) Puppet Master Installation on FIPS enabled RHEL fails
Title: Message Title
Matt Mason updated an issue
Puppet / PUP-9641
Puppet Master Installation on FIPS enabled RHEL fails
Change By:
Matt Mason
*Puppet Version: 5.5.10* *Puppet Server Version: 2018.1.7* *OS Name/Version: RHEL 7.6*Immediately after a successful installation/upgrade of Puppet 2018.1.7 on a FIPS enabled RHEL7.6 system, running puppet agent -t on the master node fails with the following error:{quote}Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Function Call, Unable to generate package repository configuration. Platform described by facts['platform_tag'] 'redhatfips-7-x86_64' is not a known master platform. (file: /opt/puppetlabs/puppet/modules/puppet_enterprise/manifests/repo/config.pp, line: 158, column: 9){quote} This issue isn't observed after a successful installation of Puppet 2019.0.1 in the same configuration.*Desired Behavior:* ** Puppet installation of the LTS branch should not have an issue installing on FIPS enabled systems.*Actual Behavior:*Using Puppet facts show on the system in the two different configurations (2018 and 2019) shows the platform_tag fact to be identical in both configurations when FIPS mode is enabled for the system:"platform_tag": "redhatfips-7-x86_64",
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (BOLT-1246) As a end user I expect the Packages for Bolt to be usable within a secure environment with little friction.
Title: Message Title Adam Buxton created an issue Puppet Task Runner / BOLT-1246 As a end user I expect the Packages for Bolt to be usable within a secure environment with little friction. Issue Type: Improvement Assignee: Unassigned Created: 2019/04/15 5:55 AM Priority: Normal Reporter: Adam Buxton The package for Bolt includes a passworded zip file for the tests, which causes issue with change management and automated acceptance tests that are not ruby based. please provide documentation of this, or exclude from the package rpm. ``` Items skipped from scanItem path Reason: Action taken C:\Downloads\puppet-bolt-1.16.0-1.el7.x86_64.rpm=>puppet-bolt-1.16.0-1.el7.gz=>(xz stream)=>.=>opt=>puppetlabs=>bolt=>lib=>ruby=>gems=>2.5.0=>cache=>rubyzip-1.2.2.gem=>data.tar.gz=>(gzip)=>test=>data="" Password-protected Not scanned(file was password-protected) C:\Downloads\puppet-bolt-1.16.0-1.el7.x86_64.rpm=>puppet-bolt-1.16.0-1.el7.gz=>(xz stream)=>.=>opt=>puppetlabs=>bolt=>lib=>ruby=>gems=>2.5.0=>gems=>rubyzip-1.2.2=>test=>data="" Password-protected Not scanned(file was password-protected) ``` Add Comment
Jira (PUP-9564) Puppet upgrades debian packages with pending updates when setting them on hold
Title: Message Title Alexandru Popa assigned an issue to Alexandru Popa Puppet / PUP-9564 Puppet upgrades debian packages with pending updates when setting them on hold Change By: Alexandru Popa Assignee: Alexandru Popa Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9642) puppet device permissions preventing reading dirs
Title: Message Title David Schmitt moved an issue Puppet / PUP-9642 puppet device permissions preventing reading dirs Change By: David Schmitt Key: FM PUP - 7133 9642 Project: Modules [Internal] Puppet Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (PUP-9331) Puppet Runs fail if leftovers in /var/spool/cron are present
Title: Message Title Alexandru Popa commented on PUP-9331 Re: Puppet Runs fail if leftovers in /var/spool/cron are present Hey Sebastian, Karthikeyan Kanagaraj, Please note that a fix for this issue was included in puppet agent 5.5.9 and 6.0.5. All newer versions of the puppet agent should have this. We've were able to this issue in 5.5.8 and were able to confirm that it's fixed in 6.4.0. Please re-open the ticket if the issue still exists on the latest puppet agent versions. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
