Jira (FACT-3163) Support for OpenBSD
Title: Message Title Sebastian Reitenbach commented on FACT-3163 Re: Support for OpenBSD The OpenBSD support made it into the OpenBSD ports tree as patch. With that, the puppet agent is working fine. However, running/bootstrapping a puppetserver on OpenBSD would having this merged and eventually released way much easier. Anything from my side I could do about it? Add Comment This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.472895.1666383381000.9970.1676323620020%40Atlassian.JIRA.
Jira (FACT-3163) Support for OpenBSD
Title: Message Title Sebastian Reitenbach created an issue Facter / FACT-3163 Support for OpenBSD Issue Type: Improvement Affects Versions: FACT 4.2.13 Assignee: Unassigned Components: Facter 4 Created: 2022/10/21 1:16 PM Labels: os Priority: Normal Reporter: Sebastian Reitenbach Facter 4 doesn't support OpenBSD, that's too bad and should change Add Comment
Jira (FACT-1883) facter 3.11.4 build broken on OpenBSD utmpx is not available
Title: Message Title Sebastian Reitenbach commented on FACT-1883 Re: facter 3.11.4 build broken on OpenBSD utmpx is not available took me a while to get to it, but see: https://github.com/puppetlabs/facter/pull/1750 I went the I think more elegant route, adding a configure check, and defining HAVE_UTMPX_H in case the header file is found. Based on that define, I compile the utmpx_file.cc and made some changes to the uptime_resolver.c, to only use the fallback of calling the uptime binary when it's not available. does that look good? 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-1883) facter 3.11.4 build broken on OpenBSD utmpx is not available
Title: Message Title Sebastian Reitenbach commented on FACT-1883 Re: facter 3.11.4 build broken on OpenBSD utmpx is not available Hi Brannan, I guess adding a configure script, checking for availability of utmpx.h would be the most clean thing to do, however, I'm not overly intimate with cmake, as well as c++ is not my most favourite language. So, if the only thing I can come up with, would be a simple: #ifdef _OpenBSD_ #else ... also OK? 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-1883) facter 3.11.4 build broken on OpenBSD utmpx is not available
Title: Message Title Sebastian Reitenbach created an issue Facter / FACT-1883 facter 3.11.4 build broken on OpenBSD utmpx is not available Issue Type: Bug Affects Versions: FACT 3.11.4 Assignee: Unassigned Created: 2018/09/17 6:29 AM Environment: OpenBSD 6.3 amd64 Priority: Normal Reporter: Sebastian Reitenbach in the uptime resolver, facter 3.11.3 was just calling out to the "uptime" binary, in 3.11.4, that change to get the uptime via the utmpx interface, which apparently is not available on OpenBSD, and therefore breaks building. Add Comment
Jira (PDB-3857) Error during garbage collection: java.sql.BatchUpdateException
Title: Message Title Sebastian Reitenbach commented on PDB-3857 Re: Error during garbage collection: java.sql.BatchUpdateException Russell Mull thanks for the info, I don't do funny things with custom facts I think then I feel safe and will actually update the official OpenBSD pupptedb package for OpenBSD -current Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574) -- 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-3857) Error during garbage collection: java.sql.BatchUpdateException
Title: Message Title Sebastian Reitenbach commented on PDB-3857 Re: Error during garbage collection: java.sql.BatchUpdateException Russell Mull yes, as I gave it in the Environment info, I'm running PostgreSQL 10.1. another note: I updated from 5.1.3, which did not bring these errors/warnings. But reading the CHANGELOG, I guess the garbage collection was redone/update in that version, and now that's new. thanks Sebastian Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574) -- 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-3857) Error during garbage collection: java.sql.BatchUpdateException
Title: Message Title Sebastian Reitenbach commented on PDB-3857 Re: Error during garbage collection: java.sql.BatchUpdateException indeed I get errors logged there as well, should have provided them with the initial report: 2018-03-01 05:53:50.658 CET [89665] ERROR: set-returning functions are not allowed in CASE at character 559 2018-03-01 05:53:50.658 CET [89665] HINT: You might be able to move the set-returning function into a LATERAL FROM item. 2018-03-01 05:53:50.658 CET [89665] STATEMENT: with recursive live_paths(key, path, value) as (select key, key as path, value from (select (jsonb_each(stable||volatile)).* from factsets) as base_case union all select sub_path as key, sub_paths.path||'#~'||sub_path as path, sub_value as value from (select * from (select path, case jsonb_typeof(value) when 'object' then (jsonb_each(value)).key when 'array' then generate_series(0, jsonb_array_length(value - 1))::text end as sub_path, case jsonb_typeof(value) when 'object' then (jsonb_each(value)).value when 'array' then jsonb_array_elements(value) end as sub_value from live_paths) as candidates where candidates.sub_path is not null) as sub_paths) delete from fact_paths fp where not exists (select 1 from live_paths where live_paths.path = fp.path) Add Comment This message was sent by Atlassian JIRA (v7.5.1#75006-sha1:7df2574) -- 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
Jira (PDB-3857) Error during garbage collection: java.sql.BatchUpdateException
Title: Message Title
Sebastian Reitenbach created an issue
PuppetDB / PDB-3857
Error during garbage collection: java.sql.BatchUpdateException
Issue Type:
Bug
Affects Versions:
PDB 5.2.0
Assignee:
Unassigned
Components:
PuppetDB
Created:
2018/02/26 2:02 PM
Environment:
Puppet 5.4.0 postgresql-server and client: 10.1 puppetdb: 5.2.0 ruby: 2.4.3 java: jdk-1.8.0.144 OS/Version: OpenBSD 6.2-current amd64 {{cat bootstrap.cfg }} # This file is used by the application framework (trapperkeeper) to # determine what services should be loaded at boot time. # For more info, see: # https://github.com/puppetlabs/trapperkeeper/wiki/Bootstrapping # Web Server puppetlabs.trapperkeeper.services.webserver.jetty9-service/jetty9-service # Webrouting puppetlabs.trapperkeeper.services.webrouting.webrouting-service/webrouting-service # TK status puppetlabs.trapperkeeper.services.metrics.metrics-service/metrics-webservice puppetlabs.trapperkeeper.services.status.status-service/status-service puppetlabs.trapperkeeper.services.scheduler.scheduler-service/scheduler-service # PuppetDB Services puppetlabs.puppetdb.cli.services/puppetdb-service puppetlabs.puppetdb.command/command-service puppetlabs.puppetdb.pdb-routing/maint-mode-service puppetlabs.puppetdb.pdb-routing/pdb-routing-service puppetlabs.puppetdb.config/config-service# NREPL puppetlabs.trapperkeeper.services.nrepl.nrepl-service/nrepl-service# Dashboard redirect: remove to disable puppetlabs.puppetdb.dashboard/dashboard-redirect-service {{}}{{cat database.ini }} [database] classname = org.postgresql.Driver subprotocol = postgresq subname = //localhost:5432/puppetdb username = puppetdb password = password gc-interval = 60 log-slow-statements = 10 syntax_pgs = true node-ttl = 0s node-purge-ttl = 0s report-ttl = 14d conn-max-age = 60 conn-keep-alive = 45 conn-lifetime = 0
Priority:
Normal
Reporter:
Sebastian Reitenbach
Jira (FACT-1675) virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Title: Message Title Sebastian Reitenbach commented on FACT-1675 Re: virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm I created a pull request to address the issue here: https://github.com/puppetlabs/facter/pull/1591 Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- 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-1675) virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Title: Message Title
Sebastian Reitenbach updated an issue
Facter / FACT-1675
virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Change By:
Sebastian Reitenbach
For a OpenBSD vm running within OpenBSD's hypervisor vmm, the facts 'virtual' and 'is_virtual' are wrong.current status:{ { quote} # facter virtualphysical# facter is_virtual# false# facter dmi { bios => { vendor => "OpenBSD"}} {quote } }
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
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-1675) virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Title: Message Title
Sebastian Reitenbach updated an issue
Facter / FACT-1675
virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Change By:
Sebastian Reitenbach
For a OpenBSD vm running within OpenBSD's hypervisor vmm, the facts 'virtual' and 'is_virtual' are wrong.current status:{ quote} { # facter virtualphysical# facter is_virtual# false# facter dmi { bios => { vendor => "OpenBSD"}} {quote } }
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
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-1675) virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Title: Message Title
Sebastian Reitenbach updated an issue
Facter / FACT-1675
virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Change By:
Sebastian Reitenbach
For a OpenBSD vm running within OpenBSD's hypervisor vmm, the facts 'virtual' and 'is_virtual' are wrong.current status:{{ # facter virtualphysical# facter is_virtual# false# facter dmi { bios => { vendor => "OpenBSD"}} }}
Add Comment
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
--
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-1675) virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Title: Message Title
Sebastian Reitenbach created an issue
Facter / FACT-1675
virtual and is_virtual facts are wrong for OpenBSD VMs running within OpenBSD hypervisor vmm
Issue Type:
Bug
Affects Versions:
FACT 3.7.0
Assignee:
Unassigned
Components:
Community
Created:
2017/06/30 12:07 AM
Environment:
OpenBSD VM running within OpenBSD's hypervisor vmm
Priority:
Normal
Reporter:
Sebastian Reitenbach
For a OpenBSD vm running within OpenBSD's hypervisor vmm, the facts 'virtual' and 'is_virtual' are wrong.
current status: {{# facter virtual physical
facter is_virtual
false
Jira (PUP-6365) trusted facts not available when running "puppet master" webrick server
Title: Message Title Sebastian Reitenbach commented on PUP-6365 Re: trusted facts not available when running "puppet master" webrick server based on comment on the PR, I retried again without the patch, and it is working. Don't know what odd happened to initially create the patch, and report here. In the meantime, I updated ruby from 2.2.4 to 2.2.5, maybe that made it work without the patch? don't know Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-6366) trusted facts with apache/nginx and puppetmaster unicorn
Title: Message Title Sebastian Reitenbach commented on PUP-6366 Re: trusted facts with apache/nginx and puppetmaster unicorn Puppet 4 and friends just arrived in OpenBSD ports tree, but still no puppet-server yet Anyways, with Puppet4, the same problem exists. See PR against the master branch https://github.com/puppetlabs/puppet/pull/5013 Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-6366) trusted facts with apache/nginx and puppetmaster unicorn
Title: Message Title
Sebastian Reitenbach updated an issue
Puppet / PUP-6366
trusted facts with apache/nginx and puppetmaster unicorn
Change By:
Sebastian Reitenbach
I have gunicorn running behind nginx, but want to make use of trusted facts, but that doesn't seem to work out of the box.Some debugging, I found thelib/puppet/network/http/rack/rest.rb, esp. the +ExportCertDatacomment in it. This is only available in Apache, so switched to useapache in front of unicorn, but still no luck.I figured that running unicorn behind apache reverse proxying, theenvironment variable is not available. Therefore I added an additionalheader that gets passed to unicorn: X-SSL-Client-Cert.However, that header is sent as single line from Apache to unicorn,and not as valid PEM encoded certificate. Therefore the gsub!manipulations to restore a valid PEM certificate again. (see the attached patch)With the attached patch, it works for Apache, just add this to the vhost configuration:RequestHeader set X-SSL-Client-Cert %{SSL_CLIENT_CERT}eWith nginx, there is a bit more trouble. Nginx has $ssl_client_cert variable aswell, but nginx passes that variable on as multi-line header. Doh!Unicorn doesn't like that at all.Therefore have to use nginx lua module, and add this: location / {set_by_lua $client_cert " if gx.var.ssl_client_raw_cert then return ngx.var.ssl_client_raw_cert:gsub('\\n',' ') end ";proxy_set_header X-SSL-Client-Cert $client_cert;}So, that patch makes trusted facts available to the puppetmaster when runningwith unicorn behind apache or nginx.
Add Comment
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Jira (PUP-6366) trusted facts with apache/nginx and puppetmaster unicorn
Title: Message Title Sebastian Reitenbach commented on PUP-6366 Re: trusted facts with apache/nginx and puppetmaster unicorn Alright, did the PR against 3.x branch, see https://github.com/puppetlabs/puppet/pull/4997 I you prefer against master or stable, let me know, and I'll create other PR. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-6366) trusted facts with apache/nginx and puppetmaster unicorn
Title: Message Title Sebastian Reitenbach commented on PUP-6366 Re: trusted facts with apache/nginx and puppetmaster unicorn I'm aware that the 3.8 is kind of not "state of the art" anymore. But there is no puppet-server package for OpenBSD yet, so that's what I use answering here for both tickets, it's the 3.x branch to where to do the PR against? BTW: just commited this fix, and the one to PUP-6365 to OpenBSD ports tree puppet port/package. Add Comment This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9) -- 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-6366) trusted facts with apache/nginx and puppetmaster unicorn
Title: Message Title Sebastian Reitenbach created an issue Puppet / PUP-6366 trusted facts with apache/nginx and puppetmaster unicorn Issue Type: Bug Affects Versions: PUP 3.8.7 Assignee: Henrik Lindberg Attachments: puppet_unicorn.diff Components: Networking Services Created: 2016/05/27 3:29 AM Environment: node and master OpenBSD 6.0-beta, puppet 3.8.7, ruby 2.2.4, nginx-1.10.0, gunicorn 5.0.1 Priority: Normal Reporter: Sebastian Reitenbach I have gunicorn running behind nginx, but want to make use of trusted facts, but that doesn't seem to work out of the box. Some debugging, I found the lib/puppet/network/http/rack/rest.rb, esp. the +ExportCertData comment in it. This is only
Jira (PUP-6365) trusted facts not available when running "puppet master" webrick server
Title: Message Title Sebastian Reitenbach created an issue Puppet / PUP-6365 trusted facts not available when running "puppet master" webrick server Issue Type: Bug Affects Versions: PUP 3.8.7 Assignee: Henrik Lindberg Attachments: puppet_webrick.diff Components: Networking Services Created: 2016/05/27 2:56 AM Environment: nodes and master are on: OpenBSD 6.0-beta, Puppet 3.8.7, ruby 2.2.4 Labels: trusted facts Priority: Normal Reporter: Sebastian Reitenbach
Jira (PUP-5746) File name missing in puppet-master error message about Forbidden request:
Title: Message Title
Sebastian Reitenbach created an issue
Puppet / PUP-5746
File name missing in puppet-master error message about Forbidden request:
Issue Type:
Bug
Affects Versions:
PUP 3.8.5
Assignee:
Unassigned
Created:
2016/01/24 10:02 AM
Environment:
Using puppet 3.8.5 package on OpenBSD 5.9, ruby 2.2.3.
sebastia@galen:~> facter | grep -i openbsd kernel => OpenBSD operatingsystem => OpenBSD os => {"name"=>"OpenBSD", "family"=>"OpenBSD", "release"=>{"major"=>"5", "minor"=>"9", "full"=>"5.9-beta"}} osfamily => OpenBSD rubyplatform => x86_64-openbsd sebastia@galen:~> facter | grep -i vers augeasversion => 1.4.0 facterversion => 2.4.4 kernelmajversion => 5.9 kernelversion => 5.9 puppetversion => 3.8.5 rubyversion => 2.2.3
Priority:
Normal
Reporter:
Sebastian Reitenbach
On my puppetmaster I have a few things configured in /etc/puppet/auth.conf for file serving, now I accidently applied wrong profile to a node, and that was not allowed to access some files.
I found (expected) error messages like this in the logs:
Jan 23 22:55:22 galen puppet-master[20]: Denying access: Forbidden request: erewon.example.com(2001:470:1234::44) access to /file_metadata/puppet_ssl_private_keys/user.pem [find] authenticated
Jira (HI-233) Support array merge for automatic parameter lookup
Title: Message Title Sebastian Reitenbach commented on HI-233 Re: Support array merge for automatic parameter lookup Hi, I was just head scratching and getting grey hair, until I re-read the link mentioned in the initial report here, in order to figure out that there is only priority lookup in Puppet automatic Parameter lookup functionality. However, maybe an easy, backward compatible solution could be to add a puppet.conf entry to the [master] section, something along the lines: parameter_lookup = priority that would be the default, so being/staying backward compatible. People that want to match the automatic parameter lookup to match what hiera_array() or hiera_hash() is doing, they can change the puppet.conf parameter to another value, i.e. merge or whatever it will be. Would that be a feasible way? thanks, Sebastian Add Comment This message was sent by Atlassian JIRA (v6.3.10#6340-sha1:7ea293a) -- 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. For more options, visit https://groups.google.com/d/optout.
Jira (HI-301) %{hiera('myvar')} should be able to lookup values within hashes
Title: Message Title
Sebastian Reitenbach created an issue
Hiera / HI-301
%{hiera('myvar')} should be able to lookup values within hashes
Issue Type:
New Feature
Assignee:
Unassigned
Created:
2014/12/08 5:24 AM
Environment:
OS is OpenBSD 5.6 -current, hiera 1.3.4, Puppet 3.7.3.
Priority:
Normal
Reporter:
Sebastian Reitenbach
hiera lookup functions can only resolve strings, but it would be nice if it also could retrieve values from within (nested) arrays and or hashes.
I.e. assume configuration of a database listener port, and an application that connects to it.
mydb::params: port: 12345
myapp::params: port: 12345
specifying the port in two places, it would be helpful, to be able to specify the following:
mydb::params: port: 12345 myapp::params: port: % {hiera('mydb::params:port')}
And it would lookup the value of the port key in the hash mydb::params.
my current workaround is: globals::dbport: 12345
mydb::params: port: % {hiera('globals::dbport')}
myapp::params: port: % {hiera('globals::dbport')}
but this workaround still feels a bit clumsy.
