Jira (PDB-5466) All-numeric password in database.ini is parsed as integer, not string
Title: Message Title
Chris Roddy commented on PDB-5466
Re: All-numeric password in database.ini is parsed as integer, not string
2022-03-10T19:15:42.482Z ERROR [p.t.internal] Error during service init!!! clojure.lang.ExceptionInfo: Value does not match schema: {:password (not (instance? java.lang.String 123456))} at schema.core$validator$fn__6137.invoke(core.clj:155) at schema.core$validate.invokeStatic(core.clj:164) at schema.core$validate.invoke(core.clj:159) at puppetlabs.puppetdb.config$warn_and_validate.invokeStatic(config.clj:50) at puppetlabs.puppetdb.config$warn_and_validate.invoke(config.clj:45) at puppetlabs.puppetdb.config$validate_and_default_incoming_config.invokeStatic(config.clj:286) at puppetlabs.puppetdb.config$validate_and_default_incoming_config.invoke(config.clj:283) at puppetlabs.puppetdb.config$fix_up_db_settings.invokeStatic(config.clj:419) at puppetlabs.puppetdb.config$fix_up_db_settings.invoke(config.clj:414) at puppetlabs.puppetdb.config$configure_dbs$fn__24178.invoke(config.clj:461) at clojure.core$update.invokeStatic(core.clj:6196) at clojure.core$update.invoke(core.clj:6188) at puppetlabs.puppetdb.config$configure_dbs.invokeStatic(config.clj:461) at puppetlabs.puppetdb.config$configure_dbs.invoke(config.clj:451) at puppetlabs.puppetdb.config$convert_config.invokeStatic(config.clj:514) at puppetlabs.puppetdb.config$convert_config.invoke(config.clj:510) at puppetlabs.puppetdb.config$process_config_BANG_.invokeStatic(config.clj:672) at puppetlabs.puppetdb.config$process_config_BANG_.invoke(config.clj:668) at puppetlabs.pe_puppetdb_extensions.config$process_config_for_sync.invokeStatic(config.clj:148) at puppetlabs.pe_puppetdb_extensions.config$process_config_for_sync.invoke(config.clj:144) at puppetlabs.puppetdb.config$init_config_service.invokeStatic(config.clj:705) at puppetlabs.puppetdb.config$init_config_service.invoke(config.clj:703) at puppetlabs.puppetdb.config$create_defaulted_config_service$reify_24405$service_fnk21933auto_positional$reify24414$fn_24415.invoke(config.clj:734) at puppetlabs.puppetdb.utils$call_unless_shutting_down.invokeStatic(utils.clj:386) at puppetlabs.puppetdb.utils$call_unless_shutting_down.invoke(utils.clj:383) at puppetlabs.puppetdb.config$create_defaulted_config_service$reify_24405$service_fnk21933auto_positional$reify_24414.init(config.clj:732) at puppetlabs.trapperkeeper.services$eval21731$fn_21732$G21719_21735.invoke(services.clj:9) at puppetlabs.trapperkeeper.services$eval21731$fn_21732$G21718_21739.invoke(services.clj:9) at puppetlabs.trapperkeeper.internal$eval22315$run_lifecycle_fn_BANG__22322$fn_22323.invoke(internal.clj:196) at puppetlabs.trapperkeeper.internal$eval22315$run_lifecycle_fn_BANG___22322.invoke(internal.clj:179) at puppetlabs.trapperkeeper.internal$eval22344$run_lifecycle_fns_22349$fn_22350.invoke(internal.clj:229) at puppetlabs.trapperkeeper.internal$eval22344$run_lifecycle_fns__22349.invoke(internal.clj:206) at puppetlabs.trapperkeeper.internal$eval22969$build_app_STAR__22978$fn$reify_22990.init(internal.clj:602) at puppetlabs.trapperkeeper.internal$eval23017$boot_services_for_app_STAR_STAR_23024$fn23025$fn_23027.invoke(internal.clj:630) at puppetlabs.trapperkeeper.internal$eval23017$boot_services_for_app_STAR_STAR_23024$fn_23025.invoke(internal.clj:629) at puppetlabs.trapperkeeper.internal$eval23017$boot_services_for_app_STAR_STAR__23024.invoke(internal.clj:623) at clojure.core$partial$fn__5841.invoke(core.clj:2630) at puppetlabs.trapperkeeper.internal$eval22389$initialize_lifecycle_worker_22
Jira (PDB-5466) All-numeric password in database.ini is parsed as integer, not string
Title: Message Title
Chris Roddy updated an issue
PuppetDB / PDB-5466
All-numeric password in database.ini is parsed as integer, not string
Change By:
Chris Roddy
If database.ini contains an all-numeric password, e.g. 'password = 123456', the value is parsed as being an integer rather than a string, producing the service will not start, and it produces a confusing error in puppetdb.log:{{{}clojure.lang.ExceptionInfo: Value does not match schema: {:password (not (instance? java.lang.String 123456)){When I set password to a value containing a letter, even when that password is wrong for my installation (e.g. I am using the default certificate authentication), the service starts fine.I discovered this on PDB 6.17.0, included with PE 2019.8.4. I am not sure what versions it affects.
Add Comment
This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d)
--
You received this message because you are subscribed to the Google Groups "Puppet Bugs" group.
To unsubscribe from this group and stop receiving
Jira (PDB-5466) All-numeric password in database.ini is parsed as integer, not string
Title: Message Title
Chris Roddy updated an issue
PuppetDB / PDB-5466
All-numeric password in database.ini is parsed as integer, not string
Change By:
Chris Roddy
If database.ini contains an all-numeric password, e.g. 'password = 123456', the value is parsed as being an integer rather than a string, producing a confusing error in puppetdb.log:{{ {} clojure.lang.ExceptionInfo: Value does not match schema: \ {:password (not (instance? java.lang.String 123456)) { }}} } When I set password to a value containing a letter, even when that password is wrong for my installation (e.g. I am using the default certificate authentication), the service starts fine.I discovered this on PDB 6.17.0, included with PE 2019. 9 8 .4. I am not sure what versions it affects.
Add Comment
This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d)
--
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 p
Jira (PDB-5466) All-numeric password in database.ini is parsed as integer, not string
Title: Message Title
Chris Roddy created an issue
PuppetDB / PDB-5466
All-numeric password in database.ini is parsed as integer, not string
Issue Type:
Bug
Assignee:
Unassigned
Created:
2022/03/10 11:24 AM
Priority:
Normal
Reporter:
Chris Roddy
If database.ini contains an all-numeric password, e.g. 'password = 123456', the value is parsed as being an integer rather than a string, producing a confusing error in puppetdb.log: clojure.lang.ExceptionInfo: Value does not match schema: {:password (not (instance? java.lang.String 123456))} When I set password to a value containing a letter, even when that password is wrong for my installation (e.g. I am using the default certificate authentication), the service starts fine. I discovered this on PDB 6.17.0, included with PE 2019.9.4. I am not sure what versions it affects.
Add Comment
Jira (HI-612) Cannot use URIs that require escaping after interpolation
Title: Message Title Chris Roddy commented on HI-612 Re: Cannot use URIs that require escaping after interpolation The related issue and pull request I filed on hiera-http are: https://github.com/crayfishx/hiera-http/issues/79 https://github.com/crayfishx/hiera-http/pull/80 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-4321) Typo in blacklist configuration docs
Title: Message Title Chris Roddy commented on PDB-4321 Re: Typo in blacklist configuration docs I have filed pull request #2878 for this issue. 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-4321) Typo in blacklist configuration docs
Title: Message Title Chris Roddy updated an issue PuppetDB / PDB-4321 Typo in blacklist configuration docs Change By: Chris Roddy Summary: Typo in blacklist configuration docs 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-4321) Typo in configuration docs
Title: Message Title Chris Roddy created an issue PuppetDB / PDB-4321 Typo in configuration docs Issue Type: Bug Assignee: Unassigned Components: PuppetDB Created: 2019/03/28 2:05 PM Priority: Normal Reporter: Chris Roddy The documentation for the facts blacklist contains a regex .*xyz.*, but the asterisks are not escaped so it renders on the docs website as .xyz. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (HI-612) Cannot use URIs that require escaping after interpolation
Title: Message Title Chris Roddy commented on HI-612 Re: Cannot use URIs that require escaping after interpolation We've worked around it by using stdlib's uriescape() as you suggested to pre-escape the variable (e.g. $appname) and assign it to a different one (e.g. $appname_escaped). This also required us to modify the hiera-http backend to remove its now-double URI escaping. I think that the upshot of this is that in order to use variables _at all _that must be escaped to be a part of URIs, the backends must also necessarily be modified to avoid double-escaping. So I am now even more convinced that, down the road, we should perform the escaping inside expand_uris as I proposed. I'll raise this on hiera-http separately, because I believe that its current URI escaping behavior is only useful for escaping things that are part of the URI in the Hiera config file, and not for things coming from interpolation. 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 (HI-612) Cannot use URIs that require escaping after interpolation
Title: Message Title Chris Roddy created an issue Hiera / HI-612 Cannot use URIs that require escaping after interpolation Issue Type: Bug Affects Versions: HI 3.4.3 Assignee: Unassigned Created: 2019/03/25 10:15 AM Priority: Normal Reporter: Chris Roddy When I provide uris, and when a value interpolated into the URI from a variable needs to be escaped in order to be a valid URI, the lookup will fail because the URI given to Ruby's URI module is invalid. For example, assume that I set up the hiera-http backend: hierarchy: - name: "my http backend" lookup_key: hiera_http options: output: json
Jira (PUP-9357) Noop exec debug logging should include the command
Title: Message Title Chris Roddy commented on PUP-9357 Re: Noop exec debug logging should include the command I don't have specific customer stories to support it, but it seems intuitively obvious to me that those attributes should support Sensitive. 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-9357) Noop exec debug logging should include the command
Title: Message Title
Chris Roddy updated an issue
Puppet / PUP-9357
Noop exec debug logging should include the command
Change By:
Chris Roddy
When running in noop mode, debug logging for exec resources includes e.g. the unless and onlyif commands, but it does not log the command that would be run, instead merely logging that it has not yet been run and should have been. Because an exec's command is frequently assembled using variable interpolation (and therefore can't be just read from the manifest conclusively), and because the resource will often have a custom title, users running with --noop --debug would likely benefit from seeing the command itself in debug output.There are other ways of getting this information, so it's not a big problem, but it would be a nice thing to have. {{ % /opt/puppetlabs/puppet/bin/puppet apply --noop --debug -e "exec { 'example': command => '/bin/true', unless => '/bin/false', }"--- 8< ---Info: Applying configuration version '1544556833'Debug: Exec[example](provider=posix): Executing check '/bin/false'Debug: Executing: '/bin/false'Notice: /Stage[main]/Main/Exec[example]/returns: current_value 'notrun', should be ['0'] (noop)Debug: /Stage[main]/Main/Exec[example]: The container Class[Main] will propagate my refresh eventNotice: Class[Main]: Would have triggered 'refresh' from 1 eventDebug: Class[Main]: The container Stage[main] will propagate my refresh eventNotice: Stage[main]: Would have triggered 'refresh' from 1 eventDebug: Finishing transaction 47213377716240Debug: Storing stateDebug: Pruned old state cache entries in 0.00 secondsDebug: Stored state in 0.01 secondsNotice: Applied catalog in 0.10 seconds--- 8< --- }}
Add Comment
Jira (PUP-9357) Noop exec debug logging should include the command
Title: Message Title
Chris Roddy created an issue
Puppet / PUP-9357
Noop exec debug logging should include the command
Issue Type:
Improvement
Assignee:
Unassigned
Created:
2018/12/11 11:37 AM
Priority:
Normal
Reporter:
Chris Roddy
When running in noop mode, debug logging for exec resources includes e.g. the unless and onlyif commands, but it does not log the command that would be run, instead merely logging that it has not yet been run and should have been. Because an exec's command is frequently assembled using variable interpolation (and therefore can't be just read from the manifest conclusively), and because the resource will often have a custom title, users running with --noop --debug would likely benefit from seeing the command itself in debug output. There are other ways of getting this information, so it's not a big problem, but it would be a nice thing to have. ```% /opt/puppetlabs/puppet/bin/puppet apply --noop --debug -e "exec { 'example': command => '/bin/true', unless => '/bin/false', } " — 8< — Info: Applying configuration version '1544556833' Debug: Exec[example](provider=posix): Executing check '/bin/false' Debug: Executing: '/bin/false' Notice: /Stage[main]/Main/Exec[example]/returns: current_value 'notrun', should be ['0'] (noop) Debug: /Stage[main]/Main/Exec[example]: The container Class[Main] will propagate my refresh event Notice: Class[Main]: Would have triggered 'refresh' from 1 event Debug: Class[Main]: The container Stage[main] will propagate my refresh event Notice: Stage[main]: Would have triggered 'refresh' from 1 event Debug: Finishing transaction 47213377716240 Debug: Storing state Debug: Pruned old state cache entries in 0.00 seconds Debug: Stored state in 0.01 seconds Notice: Applied catalog in 0.10 seconds — 8< —
Jira (PUP-9357) Noop exec debug logging should include the command
Title: Message Title
Chris Roddy updated an issue
Puppet / PUP-9357
Noop exec debug logging should include the command
Change By:
Chris Roddy
When running in noop mode, debug logging for exec resources includes e.g. the unless and onlyif commands, but it does not log the command that would be run, instead merely logging that it has not yet been run and should have been. Because an exec's command is frequently assembled using variable interpolation (and therefore can't be just read from the manifest conclusively), and because the resource will often have a custom title, users running with --noop --debug would likely benefit from seeing the command itself in debug output.There are other ways of getting this information, so it's not a big problem, but it would be a nice thing to have. ``` {{ % /opt/puppetlabs/puppet/bin/puppet apply --noop --debug -e "exec { 'example': command => '/bin/true', unless => '/bin/false', }"--- 8< ---Info: Applying configuration version '1544556833'Debug: Exec[example](provider=posix): Executing check '/bin/false'Debug: Executing: '/bin/false'Notice: /Stage[main]/Main/Exec[example]/returns: current_value 'notrun', should be ['0'] (noop)Debug: /Stage[main]/Main/Exec[example]: The container Class[Main] will propagate my refresh eventNotice: Class[Main]: Would have triggered 'refresh' from 1 eventDebug: Class[Main]: The container Stage[main] will propagate my refresh eventNotice: Stage[main]: Would have triggered 'refresh' from 1 eventDebug: Finishing transaction 47213377716240Debug: Storing stateDebug: Pruned old state cache entries in 0.00 secondsDebug: Stored state in 0.01 secondsNotice: Applied catalog in 0.10 seconds--- 8< --- ``` }}
Add Comment
Jira (PUP-9357) Noop exec debug logging should include the command
Title: Message Title
Chris Roddy updated an issue
Puppet / PUP-9357
Noop exec debug logging should include the command
Change By:
Chris Roddy
When running in noop mode, debug logging for exec resources includes e.g. the unless and onlyif commands, but it does not log the command that would be run, instead merely logging that it has not yet been run and should have been. Because an exec's command is frequently assembled using variable interpolation (and therefore can't be just read from the manifest conclusively), and because the resource will often have a custom title, users running with --noop --debug would likely benefit from seeing the command itself in debug output.There are other ways of getting this information, so it's not a big problem, but it would be a nice thing to have.```% /opt/puppetlabs/puppet/bin/puppet apply --noop --debug -e "exec { 'example': command => '/bin/true', unless => '/bin/false', }"--- 8< ---Info: Applying configuration version '1544556833'Debug: Exec[example](provider=posix): Executing check '/bin/false'Debug: Executing: '/bin/false'Notice: /Stage[main]/Main/Exec[example]/returns: current_value 'notrun', should be ['0'] (noop)Debug: /Stage[main]/Main/Exec[example]: The container Class[Main] will propagate my refresh eventNotice: Class[Main]: Would have triggered 'refresh' from 1 eventDebug: Class[Main]: The container Stage[main] will propagate my refresh eventNotice: Stage[main]: Would have triggered 'refresh' from 1 eventDebug: Finishing transaction 47213377716240Debug: Storing stateDebug: Pruned old state cache entries in 0.00 secondsDebug: Stored state in 0.01 secondsNotice: Applied catalog in 0.10 seconds--- 8< --- ```
Add Comment
Jira (FACT-799) operatingsystemmajrelease has excessive detail on AIX
Title: Message Title Chris Roddy created an issue Facter / FACT-799 operatingsystemmajrelease has excessive detail on AIX Issue Type: Bug Affects Versions: FACT 2.2.0 Assignee: Eric Sorenson Created: 2015/01/26 1:40 PM Priority: Normal Reporter: Chris Roddy On AIX, 'operatingsystemmajrelease' shows full release information down to the patchlevel. It appears to contain just the same information as 'operatingsystemrelease'. Josh Preston at DSW says this was returning the correct (shorter) info in his proof-of-concept installations on earlier versions of PE 3.x. On PE 3.7 (Facter 2.2.0) we get these results: facter operatingsystemmajrelease operatingsystemrelease operatingsystemmajrelease => 6100-07-06-1241 operatingsystemrelease => 6100-07-06-1241 facter operatingsystemmajrelease operatingsystemrelease operatingsystemmajrelease => 5300-12-04-1119 operatingsystemrelease => 5300-12-04-1119
