Re: [Puppet Users] [PuppetDB] Error 500 'Failed to execute '/pdb/cmd/v1....'

2022-11-02 Thread Martin Alfke
Can you provide the code, you used with puppetdb module?

> On 2. Nov 2022, at 08:18, Nir Fishler  wrote:
> 
> I tried to configure it using two different methods;
> Installing PuppetDB via Puppet module
> Installing from packages
> neither one of the above had given a complete success.
> 
> On Monday, October 31, 2022 at 12:14:31 PM UTC+2 Martin Alfke wrote:
>> How did you configure puppetdb and puppetserver?
>> On Open Source we usually recommend the puppetlabs-puppetdb module.
>> 
>> 
>> 
>>> On 31. Oct 2022, at 10:39, Nir Fishler > wrote:
>>> 
>> 
>>> Hey Martin,
>>> 
>>> Thanks for your reply. 
>>> 
>>> There are three files underneath that directory:
>>> puppetdb-access.log
>>> puppetdb.log
>>> puppetdb-status.log
>>> but all seem to be empty - 0kb
>>> what does that mean?
>>> 
>>> On Monday, October 10, 2022 at 11:03:05 AM UTC+3 Martin Alfke wrote:
 Hi Nir,
 
 Please check the puppetdb log file for further error investigation.
 Usually this is located at /var/log/puppetlabs/puppetdb/puppetdb.log
 
 Hth,
 Martin
 
 
 
> On 30. Sep 2022, at 10:30, Nir Fishler > wrote:
> 
 
> Hello,
> 
> puppetserver version: 7.8.0  (CentOS 7) | hostname:  puppet-staging-srv
> puppet agent: 7.19
> puppetdb: 7.11.0-1focal (Ubuntu 20.04) | hostname: puppet-staging-srv-db
> Postgres: 12.12-0ubuntu0.20.04.1
> 
> Foreman is enabled on Puppetserver.
> Postgres is configured to work with SSL.
> 
> Getting the below error from ANY VM on the network whenever I try to sync 
> with Puppet master server.
> 
> Error message:
> Error: Could not retrieve catalog from remote server: Error 500 on 
> SERVER: Server Error: Failed to execute 
> '/pdb/cmd/v1?checksum=a0d1b67028ed455a4d8b15fd5fc846ca54d4c0a6=5=vm-ubuntu20=replace_facts=2022-09-30T07:47:13.621Z'
>  on at least 1 of the following 'server_urls': 
> https://puppet-staging-srv-db:8081 
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> 
> However, When I remove the configuration files(puppetdb.conf , values 
> from puppet.conf, routes.yaml) from the Puppet master $CONF dir, 
> everything is back to normal and sync works.
> 
> Connection between Puppet master and puppetdb and vice vesra:
> [root@puppet-staging-srv puppet] nc -zvw10 puppet-staging-srv-db 8081
> Ncat: Version 7.50 ( https://nmap.org/ncat )
> Ncat: Connected to 10.111.8.77:8081 .
> 
> root@puppet-staging-srv-db:~# nc -zvw10 puppet-staging-srv 8140
> Connection to puppet-staging-srv 8140 port [tcp/puppet] succeeded!
> 
> PuppetDB website is UP and shows zero data on 'Active Nodes' and most of 
> the fields(see screenshot snap-1.png.)
> 
> Thanks in advanced!
> 
 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com <>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/af30e761-f765-4260-978e-b4817e42f3b8n%40googlegroups.com
>  
> .
> 
 
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to puppet-users...@googlegroups.com <>.
>> 
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/puppet-users/c8eb95ed-64fc-4900-868b-791e3b0bf94fn%40googlegroups.com
>>>  
>>> .
>> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/63bfcccd-a462-41c7-9ca4-cebf537fe968n%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [Puppet Users] [PuppetDB] Error 500 'Failed to execute '/pdb/cmd/v1....'

2022-11-02 Thread Nir Fishler
I tried to configure it using two different methods;

   1. Installing PuppetDB via Puppet module
   2. Installing from packages
   
neither one of the above had given a complete success.

On Monday, October 31, 2022 at 12:14:31 PM UTC+2 Martin Alfke wrote:

> How did you configure puppetdb and puppetserver?
> On Open Source we usually recommend the puppetlabs-puppetdb module.
>
>
> On 31. Oct 2022, at 10:39, Nir Fishler  wrote:
>
> Hey Martin,
>
> Thanks for your reply. 
>
> There are three files underneath that directory:
>
>- puppetdb-access.log
>- puppetdb.log
>- puppetdb-status.log
>
> but all seem to be empty - 0kb
> what does that mean?
>
> On Monday, October 10, 2022 at 11:03:05 AM UTC+3 Martin Alfke wrote:
>
>> Hi Nir,
>>
>> Please check the puppetdb log file for further error investigation.
>> Usually this is located at /var/log/puppetlabs/puppetdb/puppetdb.log
>>
>> Hth,
>> Martin
>>
>>
>> On 30. Sep 2022, at 10:30, Nir Fishler  wrote:
>>
>> Hello,
>>
>> *puppetserver *version: 7.8.0  (CentOS 7) | *hostname*:  
>> puppet-staging-srv
>> *puppet *agent: 7.19
>> *puppetdb*: 7.11.0-1focal (Ubuntu 20.04) | *hostname*: 
>> puppet-staging-srv-db
>> *Postgres*: 12.12-0ubuntu0.20.04.1
>>
>> Foreman is enabled on Puppetserver.
>> Postgres is configured to work with SSL.
>>
>> Getting the below error from ANY VM on the network whenever I try to sync 
>> with Puppet master server.
>>
>> *Error message:*
>> Error: Could not retrieve catalog from remote server: Error 500 on 
>> SERVER: Server Error: Failed to execute 
>> '/pdb/cmd/v1?checksum=a0d1b67028ed455a4d8b15fd5fc846ca54d4c0a6=5=vm-ubuntu20=replace_facts=2022-09-30T07:47:13.621Z'
>>  
>> on at least 1 of the following 'server_urls': 
>> https://puppet-staging-srv-db:8081
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>>
>> However, When I remove the configuration files(puppetdb.conf , values 
>> from puppet.conf, routes.yaml) from the Puppet master $CONF dir, everything 
>> is back to normal and sync works.
>>
>> Connection between Puppet master and puppetdb and vice vesra:
>> [root@puppet-staging-srv puppet] *nc -zvw10 puppet-staging-srv-db 8081*
>> Ncat: Version 7.50 ( https://nmap.org/ncat )
>> Ncat: 
>> *Connected to 10.111.8.77:8081 .*
>> root@puppet-staging-srv-db:~# *nc -zvw10 puppet-staging-srv 8140*
>> Connection to puppet-staging-srv 8140 port [tcp/puppet] succeeded!
>>
>> PuppetDB website is UP and shows zero data on 'Active Nodes' and most of 
>> the fields(see screenshot snap-1.png.)
>>
>> Thanks in advanced!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/af30e761-f765-4260-978e-b4817e42f3b8n%40googlegroups.com
>>  
>> 
>> .
>> 
>>
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/c8eb95ed-64fc-4900-868b-791e3b0bf94fn%40googlegroups.com
>  
> 
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/63bfcccd-a462-41c7-9ca4-cebf537fe968n%40googlegroups.com.


Re: [Puppet Users] [PuppetDB] Error 500 'Failed to execute '/pdb/cmd/v1....'

2022-10-31 Thread Martin Alfke
How did you configure puppetdb and puppetserver?
On Open Source we usually recommend the puppetlabs-puppetdb module.


> On 31. Oct 2022, at 10:39, Nir Fishler  wrote:
> 
> Hey Martin,
> 
> Thanks for your reply. 
> 
> There are three files underneath that directory:
> puppetdb-access.log
> puppetdb.log
> puppetdb-status.log
> but all seem to be empty - 0kb
> what does that mean?
> 
> On Monday, October 10, 2022 at 11:03:05 AM UTC+3 Martin Alfke wrote:
>> Hi Nir,
>> 
>> Please check the puppetdb log file for further error investigation.
>> Usually this is located at /var/log/puppetlabs/puppetdb/puppetdb.log
>> 
>> Hth,
>> Martin
>> 
>> 
>> 
>>> On 30. Sep 2022, at 10:30, Nir Fishler > wrote:
>>> 
>> 
>>> Hello,
>>> 
>>> puppetserver version: 7.8.0  (CentOS 7) | hostname:  puppet-staging-srv
>>> puppet agent: 7.19
>>> puppetdb: 7.11.0-1focal (Ubuntu 20.04) | hostname: puppet-staging-srv-db
>>> Postgres: 12.12-0ubuntu0.20.04.1
>>> 
>>> Foreman is enabled on Puppetserver.
>>> Postgres is configured to work with SSL.
>>> 
>>> Getting the below error from ANY VM on the network whenever I try to sync 
>>> with Puppet master server.
>>> 
>>> Error message:
>>> Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
>>> Server Error: Failed to execute 
>>> '/pdb/cmd/v1?checksum=a0d1b67028ed455a4d8b15fd5fc846ca54d4c0a6=5=vm-ubuntu20=replace_facts=2022-09-30T07:47:13.621Z'
>>>  on at least 1 of the following 'server_urls': 
>>> https://puppet-staging-srv-db:8081 
>>> Warning: Not using cache on failed catalog
>>> Error: Could not retrieve catalog; skipping run
>>> 
>>> However, When I remove the configuration files(puppetdb.conf , values from 
>>> puppet.conf, routes.yaml) from the Puppet master $CONF dir, everything is 
>>> back to normal and sync works.
>>> 
>>> Connection between Puppet master and puppetdb and vice vesra:
>>> [root@puppet-staging-srv puppet] nc -zvw10 puppet-staging-srv-db 8081
>>> Ncat: Version 7.50 ( https://nmap.org/ncat )
>>> Ncat: Connected to 10.111.8.77:8081 .
>>> 
>>> root@puppet-staging-srv-db:~# nc -zvw10 puppet-staging-srv 8140
>>> Connection to puppet-staging-srv 8140 port [tcp/puppet] succeeded!
>>> 
>>> PuppetDB website is UP and shows zero data on 'Active Nodes' and most of 
>>> the fields(see screenshot snap-1.png.)
>>> 
>>> Thanks in advanced!
>>> 
>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to puppet-users...@googlegroups.com <>.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/puppet-users/af30e761-f765-4260-978e-b4817e42f3b8n%40googlegroups.com
>>>  
>>> .
>>> 
>> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/c8eb95ed-64fc-4900-868b-791e3b0bf94fn%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/FCA079D2-C318-4724-BD90-3A844D25B300%40gmail.com.


Re: [Puppet Users] [PuppetDB] Error 500 'Failed to execute '/pdb/cmd/v1....'

2022-10-31 Thread Nir Fishler
Hey Martin,

Thanks for your reply. 

There are three files underneath that directory:

   - puppetdb-access.log
   - puppetdb.log
   - puppetdb-status.log
   
but all seem to be empty - 0kb
what does that mean?

On Monday, October 10, 2022 at 11:03:05 AM UTC+3 Martin Alfke wrote:

> Hi Nir,
>
> Please check the puppetdb log file for further error investigation.
> Usually this is located at /var/log/puppetlabs/puppetdb/puppetdb.log
>
> Hth,
> Martin
>
>
> On 30. Sep 2022, at 10:30, Nir Fishler  wrote:
>
> Hello,
>
> *puppetserver *version: 7.8.0  (CentOS 7) | *hostname*:  
> puppet-staging-srv
> *puppet *agent: 7.19
> *puppetdb*: 7.11.0-1focal (Ubuntu 20.04) | *hostname*: 
> puppet-staging-srv-db
> *Postgres*: 12.12-0ubuntu0.20.04.1
>
> Foreman is enabled on Puppetserver.
> Postgres is configured to work with SSL.
>
> Getting the below error from ANY VM on the network whenever I try to sync 
> with Puppet master server.
>
> *Error message:*
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
> Server Error: Failed to execute 
> '/pdb/cmd/v1?checksum=a0d1b67028ed455a4d8b15fd5fc846ca54d4c0a6=5=vm-ubuntu20=replace_facts=2022-09-30T07:47:13.621Z'
>  
> on at least 1 of the following 'server_urls': 
> https://puppet-staging-srv-db:8081
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> However, When I remove the configuration files(puppetdb.conf , values from 
> puppet.conf, routes.yaml) from the Puppet master $CONF dir, everything is 
> back to normal and sync works.
>
> Connection between Puppet master and puppetdb and vice vesra:
> [root@puppet-staging-srv puppet] *nc -zvw10 puppet-staging-srv-db 8081*
> Ncat: Version 7.50 ( https://nmap.org/ncat )
> Ncat: 
> *Connected to 10.111.8.77:8081 .*
> root@puppet-staging-srv-db:~# *nc -zvw10 puppet-staging-srv 8140*
> Connection to puppet-staging-srv 8140 port [tcp/puppet] succeeded!
>
> PuppetDB website is UP and shows zero data on 'Active Nodes' and most of 
> the fields(see screenshot snap-1.png.)
>
> Thanks in advanced!
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/af30e761-f765-4260-978e-b4817e42f3b8n%40googlegroups.com
>  
> 
> .
> 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c8eb95ed-64fc-4900-868b-791e3b0bf94fn%40googlegroups.com.


Re: [Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-18 Thread Callum McCrorie
Hi Martin,

Following on from your previous reply, I have taken the steps that you have
suggested. From here I have received two new errors. I have looked into
these and tried finding a solution and working through fixing them.
However, I have unfortunately had no success in doing so. I am wondering if
you might have any ideas / suggestions on what I should try next. The two
errors that I am facing are as follows.

Error one:

Error:
/Stage[main]/Puppetdb::Database::Postgresql/Postgresql::Server::Db[puppetdb]/Postgresql::Server::Role[puppetdb]/Postgresql_psql[CREATE
ROLE puppetdb ENCRYPTED PASSWORD ]: Could not evaluate: Error
evaluating 'unless' clause, returned pid 628818 exit 1: 'Error: Could not
execute posix command: Invalid group: postgres
'

Error two:

Error: /Stage[main]/Profiles::Puppetboard/Docker::Image[
ghcr.io/voxpupuli/puppetboard:3.5.0]/Exec[/usr/local/bin/update_docker_image.sh
ghcr.io/voxpupuli/puppetboard:3.5.0]: Could not evaluate: Could not find
command 'docker'

Thank you,

Kind regards,
Callum McCrorie
Junior Engineer/Project Management


On Thu, 13 Oct 2022 at 08:48, Martin Alfke  wrote:

> Best option is to completely remove the puppetdb service:
>
> - stop puppetdb process
> - uninstall puppetdb Package
> - remove puppetdb conf dir /etc/puppetlabs/puppetdb
>
> Now remove the puppetdb settings from puppet.conf file:
> - storeconfigs = true
> - storeconfigs_backend = puppetdb
> - reports = puppetdb
>
> Then remove the files
> /etc/puppetlabs/puppet/routes.yaml
> and
> /etc/puppetlabs/puppet/puppetdb.conf
>
> Now restart the puppetserver process.
>
> Then you can make use of the module and run the puppet agent on your
> puppet server.
>
>
>
> > On 12. Oct 2022, at 16:46, Callum McCrorie 
> wrote:
> >
> > Hi Martin,
> > I am trying to use puppetlabs-puppetdb. This is being installed via my
> > control repository. Unfortunately I am unable to start the service and
> > am running into the errors / issues that I have previously stated.
> > Thank you,
> >
> > Kind regards,
> > Callum McCrorie
> > Junior Engineer/Project Management
> >
> > On Wed, 12 Oct 2022 at 15:37, Martin Alfke  wrote:
> >>
> >> Hi Callum,
> >>
> >> in general we use Puppet to also manage the Puppet Server.
> >> Usually we recommend using puppetlabs-puppetdb, which will take care on
> postgresql and puppetdb and the required settings and even restart
> puppetserver process.
> >> Instead of trying to manually solve an issue, you should automate your
> automation (which is your Puppet server).
> >>
> >> hth,
> >> Martin
> >>
> >>> On 12. Oct 2022, at 16:05, Callum McCrorie 
> wrote:
> >>>
> >>> Thank you Martin for your help with this.
> >>> I have tried implementing what you suggested above and moving the
> database config to database.ini. Unfortunately there has been no change of
> outcome when trying to start puppetdb or when running puppet agent. There
> is also no new information / entries appearing in the .log files for
> puppetdb.
> >>> Please could you provide any other ideas of how we should debug this
> issue or things to try?
> >>>
> >>> Kind regards,
> >>> Callum McCrorie
> >>> Junior Engineer/Project Management
> >>>
> >>>
> >>>
> >>> On Tue, 11 Oct 2022 at 08:52, Martin Alfke  wrote:
> >>> Subname needs the PostgreSQL connection. Not the PuppetDB URL
> >>>
> >>> Wrong:
> >>> subname = //localhost:8081/puppetdb
> >>>
> >>> Right:
> >>> subname = //localhost:5432/puppetdb
> >>>
> >>> In my config all the database config is not in config.ini but in
> database.ini
> >>>
> >>> # /etc/puppetlabs/puppetdb/conf/database.ini
> >>> [database]
> >>>
> >>> # The database address, i.e. //HOST:PORT/DATABASE_NAME
> >>> # subname = //localhost:5432/puppetdb
> >>> subname = //localhost:5432/puppetdb
> >>>
> >>> # Connect as a specific user
> >>> # username = foobar
> >>> username = puppetdb
> >>>
> >>> # Use a specific password
> >>> # password = foobar
> >>> password = puppetdb
> >>>
> >>> # How often (in minutes) to compact the database
> >>> # gc-interval = 60
> >>> gc-interval = 60
> >>> classname = org.postgresql.Driver
> >>> subprotocol = postgresql
> >>> syntax_pgs = true
> >>> node-purge-gc-batch-limit = 25
> >>> node-ttl = 7d
> >>> node-purge-ttl = 14d
> >>> report-ttl = 14d
> >>> log-slow-statements = 10
> >>> conn-max-age = 60
> >>> conn-keep-alive = 45
> >>> conn-lifetime = 0
> >>> migrate = true
> >>>
> >>>
> >>> Hth,
> >>> Martin
> >>>
>  On 10. Oct 2022, at 15:42, Callum McCrorie 
> wrote:
> 
>  Hello,
>  I’m reaching out about an issue related to PuppetDB. I am hoping that
>  someone will be able to assist myself and my coworker in solving this
>  problem.
> 
>  When I take a look inside the puppetdb log file the error that I am
>  seeing is `ERROR [p.p.config] No subname set in the "database"
>  config`. Root to the log file is -
> /var/log/puppetlabs/puppetdb/puppetdb.log.
> 
>  If I try to start puppetdb service manually by running `systemctl
>  

Re: [Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-13 Thread Martin Alfke
Best option is to completely remove the puppetdb service:

- stop puppetdb process
- uninstall puppetdb Package
- remove puppetdb conf dir /etc/puppetlabs/puppetdb

Now remove the puppetdb settings from puppet.conf file:
- storeconfigs = true
- storeconfigs_backend = puppetdb
- reports = puppetdb

Then remove the files
/etc/puppetlabs/puppet/routes.yaml
and
/etc/puppetlabs/puppet/puppetdb.conf

Now restart the puppetserver process.

Then you can make use of the module and run the puppet agent on your puppet 
server.



> On 12. Oct 2022, at 16:46, Callum McCrorie  wrote:
> 
> Hi Martin,
> I am trying to use puppetlabs-puppetdb. This is being installed via my
> control repository. Unfortunately I am unable to start the service and
> am running into the errors / issues that I have previously stated.
> Thank you,
> 
> Kind regards,
> Callum McCrorie
> Junior Engineer/Project Management
> 
> On Wed, 12 Oct 2022 at 15:37, Martin Alfke  wrote:
>> 
>> Hi Callum,
>> 
>> in general we use Puppet to also manage the Puppet Server.
>> Usually we recommend using puppetlabs-puppetdb, which will take care on 
>> postgresql and puppetdb and the required settings and even restart 
>> puppetserver process.
>> Instead of trying to manually solve an issue, you should automate your 
>> automation (which is your Puppet server).
>> 
>> hth,
>> Martin
>> 
>>> On 12. Oct 2022, at 16:05, Callum McCrorie  wrote:
>>> 
>>> Thank you Martin for your help with this.
>>> I have tried implementing what you suggested above and moving the database 
>>> config to database.ini. Unfortunately there has been no change of outcome 
>>> when trying to start puppetdb or when running puppet agent. There is also 
>>> no new information / entries appearing in the .log files for puppetdb.
>>> Please could you provide any other ideas of how we should debug this issue 
>>> or things to try?
>>> 
>>> Kind regards,
>>> Callum McCrorie
>>> Junior Engineer/Project Management
>>> 
>>> 
>>> 
>>> On Tue, 11 Oct 2022 at 08:52, Martin Alfke  wrote:
>>> Subname needs the PostgreSQL connection. Not the PuppetDB URL
>>> 
>>> Wrong:
>>> subname = //localhost:8081/puppetdb
>>> 
>>> Right:
>>> subname = //localhost:5432/puppetdb
>>> 
>>> In my config all the database config is not in config.ini but in 
>>> database.ini
>>> 
>>> # /etc/puppetlabs/puppetdb/conf/database.ini
>>> [database]
>>> 
>>> # The database address, i.e. //HOST:PORT/DATABASE_NAME
>>> # subname = //localhost:5432/puppetdb
>>> subname = //localhost:5432/puppetdb
>>> 
>>> # Connect as a specific user
>>> # username = foobar
>>> username = puppetdb
>>> 
>>> # Use a specific password
>>> # password = foobar
>>> password = puppetdb
>>> 
>>> # How often (in minutes) to compact the database
>>> # gc-interval = 60
>>> gc-interval = 60
>>> classname = org.postgresql.Driver
>>> subprotocol = postgresql
>>> syntax_pgs = true
>>> node-purge-gc-batch-limit = 25
>>> node-ttl = 7d
>>> node-purge-ttl = 14d
>>> report-ttl = 14d
>>> log-slow-statements = 10
>>> conn-max-age = 60
>>> conn-keep-alive = 45
>>> conn-lifetime = 0
>>> migrate = true
>>> 
>>> 
>>> Hth,
>>> Martin
>>> 
 On 10. Oct 2022, at 15:42, Callum McCrorie  
 wrote:
 
 Hello,
 I’m reaching out about an issue related to PuppetDB. I am hoping that
 someone will be able to assist myself and my coworker in solving this
 problem.
 
 When I take a look inside the puppetdb log file the error that I am
 seeing is `ERROR [p.p.config] No subname set in the "database"
 config`. Root to the log file is - 
 /var/log/puppetlabs/puppetdb/puppetdb.log.
 
 If I try to start puppetdb service manually by running `systemctl
 start puppetdb` I then receive the following error message:
 `Job for puppetdb.service failed because the control process exited
 with error code.
 See "systemctl status puppetdb.service" and "journalctl -xe" for details.`
 
 Following this when looking at `journalctl -xe` I can see the error 
 message:
 `-- The unit puppetdb.service has entered the 'failed' state with
 result 'exit-code'
 Oct 04 13:37:36 puppet systemd[1]: Failed to start puppetdb Service.
 -- Subject: A start job for unit puppetdb.service has failed.'
 
 I have also included in this the PuppetDB scripts and any related scripts.
 
 The following script is for puppet.conf location is
 /etc/puppetlabs/puppet/puppet.conf.
 
 # This file can be used to override the default puppet settings.
 # See the following links for more details on what settings are available:
 # - https://puppet.com/docs/puppet/latest/config_important_settings.html
 # - https://puppet.com/docs/puppet/latest/config_about_settings.html
 # - https://puppet.com/docs/puppet/latest/config_file_main.html
 # - https://puppet.com/docs/puppet/latest/configuration.html
 [server]
 vardir = /opt/puppetlabs/server/data/puppetserver
 logdir = 

Re: [Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-12 Thread Callum McCrorie
Hi Martin,
I am trying to use puppetlabs-puppetdb. This is being installed via my
control repository. Unfortunately I am unable to start the service and
am running into the errors / issues that I have previously stated.
Thank you,

Kind regards,
Callum McCrorie
Junior Engineer/Project Management

On Wed, 12 Oct 2022 at 15:37, Martin Alfke  wrote:
>
> Hi Callum,
>
> in general we use Puppet to also manage the Puppet Server.
> Usually we recommend using puppetlabs-puppetdb, which will take care on 
> postgresql and puppetdb and the required settings and even restart 
> puppetserver process.
> Instead of trying to manually solve an issue, you should automate your 
> automation (which is your Puppet server).
>
> hth,
> Martin
>
> > On 12. Oct 2022, at 16:05, Callum McCrorie  wrote:
> >
> > Thank you Martin for your help with this.
> > I have tried implementing what you suggested above and moving the database 
> > config to database.ini. Unfortunately there has been no change of outcome 
> > when trying to start puppetdb or when running puppet agent. There is also 
> > no new information / entries appearing in the .log files for puppetdb.
> > Please could you provide any other ideas of how we should debug this issue 
> > or things to try?
> >
> > Kind regards,
> > Callum McCrorie
> > Junior Engineer/Project Management
> >
> >
> >
> > On Tue, 11 Oct 2022 at 08:52, Martin Alfke  wrote:
> > Subname needs the PostgreSQL connection. Not the PuppetDB URL
> >
> > Wrong:
> > subname = //localhost:8081/puppetdb
> >
> > Right:
> > subname = //localhost:5432/puppetdb
> >
> > In my config all the database config is not in config.ini but in 
> > database.ini
> >
> > # /etc/puppetlabs/puppetdb/conf/database.ini
> > [database]
> >
> > # The database address, i.e. //HOST:PORT/DATABASE_NAME
> > # subname = //localhost:5432/puppetdb
> > subname = //localhost:5432/puppetdb
> >
> > # Connect as a specific user
> > # username = foobar
> > username = puppetdb
> >
> > # Use a specific password
> > # password = foobar
> > password = puppetdb
> >
> > # How often (in minutes) to compact the database
> > # gc-interval = 60
> > gc-interval = 60
> > classname = org.postgresql.Driver
> > subprotocol = postgresql
> > syntax_pgs = true
> > node-purge-gc-batch-limit = 25
> > node-ttl = 7d
> > node-purge-ttl = 14d
> > report-ttl = 14d
> > log-slow-statements = 10
> > conn-max-age = 60
> > conn-keep-alive = 45
> > conn-lifetime = 0
> > migrate = true
> >
> >
> > Hth,
> > Martin
> >
> >> On 10. Oct 2022, at 15:42, Callum McCrorie  
> >> wrote:
> >>
> >> Hello,
> >> I’m reaching out about an issue related to PuppetDB. I am hoping that
> >> someone will be able to assist myself and my coworker in solving this
> >> problem.
> >>
> >> When I take a look inside the puppetdb log file the error that I am
> >> seeing is `ERROR [p.p.config] No subname set in the "database"
> >> config`. Root to the log file is - 
> >> /var/log/puppetlabs/puppetdb/puppetdb.log.
> >>
> >> If I try to start puppetdb service manually by running `systemctl
> >> start puppetdb` I then receive the following error message:
> >> `Job for puppetdb.service failed because the control process exited
> >> with error code.
> >> See "systemctl status puppetdb.service" and "journalctl -xe" for details.`
> >>
> >> Following this when looking at `journalctl -xe` I can see the error 
> >> message:
> >> `-- The unit puppetdb.service has entered the 'failed' state with
> >> result 'exit-code'
> >> Oct 04 13:37:36 puppet systemd[1]: Failed to start puppetdb Service.
> >> -- Subject: A start job for unit puppetdb.service has failed.'
> >>
> >> I have also included in this the PuppetDB scripts and any related scripts.
> >>
> >> The following script is for puppet.conf location is
> >> /etc/puppetlabs/puppet/puppet.conf.
> >>
> >> # This file can be used to override the default puppet settings.
> >> # See the following links for more details on what settings are available:
> >> # - https://puppet.com/docs/puppet/latest/config_important_settings.html
> >> # - https://puppet.com/docs/puppet/latest/config_about_settings.html
> >> # - https://puppet.com/docs/puppet/latest/config_file_main.html
> >> # - https://puppet.com/docs/puppet/latest/configuration.html
> >> [server]
> >> vardir = /opt/puppetlabs/server/data/puppetserver
> >> logdir = /var/log/puppetlabs/puppetserver
> >> rundir = /var/run/puppetlabs/puppetserver
> >> pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
> >> codedir = /etc/puppetlabs/code
> >>
> >> [master]
> >> storeconfigs = true
> >> storeconfigs_backend = puppetdb
> >> reports = store, puppetdb
> >>
> >> [agent]
> >> noop = true
> >>
> >> The next script is from puppetdb.conf location is
> >> /etc/puppetlabs/puppet/puppetdb.conf
> >>
> >> [main]
> >>  server_urls = https://puppetdb.company.com:8081
> >>
> >>
> >> The puppetdb config.ini file
> >> (/etc/puppetlabs/puppetdb/conf.d/config.ini) is as follows:
> >>
> >> #logging-config = /etc/puppetlabs/puppetdb/logback.xml

Re: [Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-12 Thread Martin Alfke
Hi Callum,

in general we use Puppet to also manage the Puppet Server. 
Usually we recommend using puppetlabs-puppetdb, which will take care on 
postgresql and puppetdb and the required settings and even restart puppetserver 
process.
Instead of trying to manually solve an issue, you should automate your 
automation (which is your Puppet server).

hth,
Martin

> On 12. Oct 2022, at 16:05, Callum McCrorie  wrote:
> 
> Thank you Martin for your help with this. 
> I have tried implementing what you suggested above and moving the database 
> config to database.ini. Unfortunately there has been no change of outcome 
> when trying to start puppetdb or when running puppet agent. There is also no 
> new information / entries appearing in the .log files for puppetdb. 
> Please could you provide any other ideas of how we should debug this issue or 
> things to try?
> 
> Kind regards,
> Callum McCrorie
> Junior Engineer/Project Management
> 
> 
> 
> On Tue, 11 Oct 2022 at 08:52, Martin Alfke  wrote:
> Subname needs the PostgreSQL connection. Not the PuppetDB URL
> 
> Wrong:
> subname = //localhost:8081/puppetdb
> 
> Right:
> subname = //localhost:5432/puppetdb
> 
> In my config all the database config is not in config.ini but in database.ini
> 
> # /etc/puppetlabs/puppetdb/conf/database.ini
> [database]
> 
> # The database address, i.e. //HOST:PORT/DATABASE_NAME
> # subname = //localhost:5432/puppetdb
> subname = //localhost:5432/puppetdb
> 
> # Connect as a specific user
> # username = foobar
> username = puppetdb
> 
> # Use a specific password
> # password = foobar
> password = puppetdb
> 
> # How often (in minutes) to compact the database
> # gc-interval = 60
> gc-interval = 60
> classname = org.postgresql.Driver
> subprotocol = postgresql
> syntax_pgs = true
> node-purge-gc-batch-limit = 25
> node-ttl = 7d
> node-purge-ttl = 14d
> report-ttl = 14d
> log-slow-statements = 10
> conn-max-age = 60
> conn-keep-alive = 45
> conn-lifetime = 0
> migrate = true
> 
> 
> Hth,
> Martin
> 
>> On 10. Oct 2022, at 15:42, Callum McCrorie  wrote:
>> 
>> Hello,
>> I’m reaching out about an issue related to PuppetDB. I am hoping that
>> someone will be able to assist myself and my coworker in solving this
>> problem.
>> 
>> When I take a look inside the puppetdb log file the error that I am
>> seeing is `ERROR [p.p.config] No subname set in the "database"
>> config`. Root to the log file is - /var/log/puppetlabs/puppetdb/puppetdb.log.
>> 
>> If I try to start puppetdb service manually by running `systemctl
>> start puppetdb` I then receive the following error message:
>> `Job for puppetdb.service failed because the control process exited
>> with error code.
>> See "systemctl status puppetdb.service" and "journalctl -xe" for details.`
>> 
>> Following this when looking at `journalctl -xe` I can see the error message:
>> `-- The unit puppetdb.service has entered the 'failed' state with
>> result 'exit-code'
>> Oct 04 13:37:36 puppet systemd[1]: Failed to start puppetdb Service.
>> -- Subject: A start job for unit puppetdb.service has failed.'
>> 
>> I have also included in this the PuppetDB scripts and any related scripts.
>> 
>> The following script is for puppet.conf location is
>> /etc/puppetlabs/puppet/puppet.conf.
>> 
>> # This file can be used to override the default puppet settings.
>> # See the following links for more details on what settings are available:
>> # - https://puppet.com/docs/puppet/latest/config_important_settings.html
>> # - https://puppet.com/docs/puppet/latest/config_about_settings.html
>> # - https://puppet.com/docs/puppet/latest/config_file_main.html
>> # - https://puppet.com/docs/puppet/latest/configuration.html
>> [server]
>> vardir = /opt/puppetlabs/server/data/puppetserver
>> logdir = /var/log/puppetlabs/puppetserver
>> rundir = /var/run/puppetlabs/puppetserver
>> pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
>> codedir = /etc/puppetlabs/code
>> 
>> [master]
>> storeconfigs = true
>> storeconfigs_backend = puppetdb
>> reports = store, puppetdb
>> 
>> [agent]
>> noop = true
>> 
>> The next script is from puppetdb.conf location is
>> /etc/puppetlabs/puppet/puppetdb.conf
>> 
>> [main]
>>  server_urls = https://puppetdb.company.com:8081
>> 
>> 
>> The puppetdb config.ini file
>> (/etc/puppetlabs/puppetdb/conf.d/config.ini) is as follows:
>> 
>> #logging-config = /etc/puppetlabs/puppetdb/logback.xml
>> 
>> #[command-processing]
>> # How many command-processing threads to use, defaults to (CPUs / 2)
>> # threads = 4
>> 
>> # How many threads can write to disk at once, defaults to min(CPUs / 2, 4)
>> # concurrent-writes = 4
>> 
>> [global]
>> vardir = /var/lib/puppetdb
>> logging-config = /var/lib/puppetdb/logback.xml
>> 
>> [database]
>> classname = org.postgresql.Driver
>> subprotocol = postgresql
>> subname = //localhost:8081/puppetdb
>> 
>> [puppetdb]
>> certificate-whitelist = /path/to/file/containing/certnames
>> disable-update-checking = false
>> 
>> The puppetdb jetty.ini file
>> 

Re: [Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-12 Thread Callum McCrorie
Thank you Martin for your help with this.
I have tried implementing what you suggested above and moving the database
config to database.ini. Unfortunately there has been no change of outcome
when trying to start puppetdb or when running puppet agent. There is also
no new information / entries appearing in the .log files for puppetdb.
Please could you provide any other ideas of how we should debug this issue
or things to try?

Kind regards,
Callum McCrorie
Junior Engineer/Project Management


On Tue, 11 Oct 2022 at 08:52, Martin Alfke  wrote:

> Subname needs the PostgreSQL connection. Not the PuppetDB URL
>
> Wrong:
> subname = //localhost:8081/puppetdb
>
> Right:
> subname = //localhost:5432/puppetdb
>
> In my config all the database config is not in config.ini but in
> database.ini
>
> # /etc/puppetlabs/puppetdb/conf/database.ini
> [database]
>
> # The database address, i.e. //HOST:PORT/DATABASE_NAME
> # subname = //localhost:5432/puppetdb
> subname = //localhost:5432/puppetdb
>
> # Connect as a specific user
> # username = foobar
> username = puppetdb
>
> # Use a specific password
> # password = foobar
> password = puppetdb
>
> # How often (in minutes) to compact the database
> # gc-interval = 60
> gc-interval = 60
> classname = org.postgresql.Driver
> subprotocol = postgresql
> syntax_pgs = true
> node-purge-gc-batch-limit = 25
> node-ttl = 7d
> node-purge-ttl = 14d
> report-ttl = 14d
> log-slow-statements = 10
> conn-max-age = 60
> conn-keep-alive = 45
> conn-lifetime = 0
> migrate = true
>
>
> Hth,
> Martin
>
> On 10. Oct 2022, at 15:42, Callum McCrorie 
> wrote:
>
> Hello,
> I’m reaching out about an issue related to PuppetDB. I am hoping that
> someone will be able to assist myself and my coworker in solving this
> problem.
>
> When I take a look inside the puppetdb log file the error that I am
> seeing is `ERROR [p.p.config] No subname set in the "database"
> config`. Root to the log file is -
> /var/log/puppetlabs/puppetdb/puppetdb.log.
>
> If I try to start puppetdb service manually by running `systemctl
> start puppetdb` I then receive the following error message:
> `Job for puppetdb.service failed because the control process exited
> with error code.
> See "systemctl status puppetdb.service" and "journalctl -xe" for details.`
>
> Following this when looking at `journalctl -xe` I can see the error
> message:
> `-- The unit puppetdb.service has entered the 'failed' state with
> result 'exit-code'
> Oct 04 13:37:36 puppet systemd[1]: Failed to start puppetdb Service.
> -- Subject: A start job for unit puppetdb.service has failed.'
>
> I have also included in this the PuppetDB scripts and any related scripts.
>
> The following script is for puppet.conf location is
> /etc/puppetlabs/puppet/puppet.conf.
>
> # This file can be used to override the default puppet settings.
> # See the following links for more details on what settings are available:
> # - https://puppet.com/docs/puppet/latest/config_important_settings.html
> # - https://puppet.com/docs/puppet/latest/config_about_settings.html
> # - https://puppet.com/docs/puppet/latest/config_file_main.html
> # - https://puppet.com/docs/puppet/latest/configuration.html
> [server]
> vardir = /opt/puppetlabs/server/data/puppetserver
> logdir = /var/log/puppetlabs/puppetserver
> rundir = /var/run/puppetlabs/puppetserver
> pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
> codedir = /etc/puppetlabs/code
>
> [master]
> storeconfigs = true
> storeconfigs_backend = puppetdb
> reports = store, puppetdb
>
> [agent]
> noop = true
>
> The next script is from puppetdb.conf location is
> /etc/puppetlabs/puppet/puppetdb.conf
>
> [main]
>  server_urls = https://puppetdb.company.com:8081
>
>
> The puppetdb config.ini file
> (/etc/puppetlabs/puppetdb/conf.d/config.ini) is as follows:
>
> #logging-config = /etc/puppetlabs/puppetdb/logback.xml
>
> #[command-processing]
> # How many command-processing threads to use, defaults to (CPUs / 2)
> # threads = 4
>
> # How many threads can write to disk at once, defaults to min(CPUs / 2, 4)
> # concurrent-writes = 4
>
> [global]
> vardir = /var/lib/puppetdb
> logging-config = /var/lib/puppetdb/logback.xml
>
> [database]
> classname = org.postgresql.Driver
> subprotocol = postgresql
> subname = //localhost:8081/puppetdb
>
> [puppetdb]
> certificate-whitelist = /path/to/file/containing/certnames
> disable-update-checking = false
>
> The puppetdb jetty.ini file
> (/etc/puppetlabs/puppetdb/conf.d/jetty.ini) is as follows:
>
> [jetty]
> # IP address or hostname to listen for clear-text HTTP. To avoid resolution
> # issues, IP addresses are recommended over hostnames.
> # Default is `localhost`.
> # host = 
>
> # Port to listen on for clear-text HTTP.
> port = 8080
>
> # The following are SSL specific settings. They can be configured
> # automatically with the tool `puppetdb ssl-setup`, which is normally
> # ran during package installation.
>
> # IP address to listen on for HTTPS connections. Hostnames can also be used
> # 

Re: [Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-11 Thread Martin Alfke
Subname needs the PostgreSQL connection. Not the PuppetDB URL

Wrong:
subname = //localhost:8081/puppetdb

Right:
subname = //localhost:5432/puppetdb

In my config all the database config is not in config.ini but in database.ini

# /etc/puppetlabs/puppetdb/conf/database.ini
[database]

# The database address, i.e. //HOST:PORT/DATABASE_NAME
# subname = //localhost:5432/puppetdb
subname = //localhost:5432/puppetdb

# Connect as a specific user
# username = foobar
username = puppetdb

# Use a specific password
# password = foobar
password = puppetdb

# How often (in minutes) to compact the database
# gc-interval = 60
gc-interval = 60
classname = org.postgresql.Driver
subprotocol = postgresql
syntax_pgs = true
node-purge-gc-batch-limit = 25
node-ttl = 7d
node-purge-ttl = 14d
report-ttl = 14d
log-slow-statements = 10
conn-max-age = 60
conn-keep-alive = 45
conn-lifetime = 0
migrate = true


Hth,
Martin

> On 10. Oct 2022, at 15:42, Callum McCrorie  wrote:
> 
> Hello,
> I’m reaching out about an issue related to PuppetDB. I am hoping that
> someone will be able to assist myself and my coworker in solving this
> problem.
> 
> When I take a look inside the puppetdb log file the error that I am
> seeing is `ERROR [p.p.config] No subname set in the "database"
> config`. Root to the log file is - /var/log/puppetlabs/puppetdb/puppetdb.log.
> 
> If I try to start puppetdb service manually by running `systemctl
> start puppetdb` I then receive the following error message:
> `Job for puppetdb.service failed because the control process exited
> with error code.
> See "systemctl status puppetdb.service" and "journalctl -xe" for details.`
> 
> Following this when looking at `journalctl -xe` I can see the error message:
> `-- The unit puppetdb.service has entered the 'failed' state with
> result 'exit-code'
> Oct 04 13:37:36 puppet systemd[1]: Failed to start puppetdb Service.
> -- Subject: A start job for unit puppetdb.service has failed.'
> 
> I have also included in this the PuppetDB scripts and any related scripts.
> 
> The following script is for puppet.conf location is
> /etc/puppetlabs/puppet/puppet.conf.
> 
> # This file can be used to override the default puppet settings.
> # See the following links for more details on what settings are available:
> # - https://puppet.com/docs/puppet/latest/config_important_settings.html 
> 
> # - https://puppet.com/docs/puppet/latest/config_about_settings.html 
> 
> # - https://puppet.com/docs/puppet/latest/config_file_main.html 
> 
> # - https://puppet.com/docs/puppet/latest/configuration.html 
> 
> [server]
> vardir = /opt/puppetlabs/server/data/puppetserver
> logdir = /var/log/puppetlabs/puppetserver
> rundir = /var/run/puppetlabs/puppetserver
> pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
> codedir = /etc/puppetlabs/code
> 
> [master]
> storeconfigs = true
> storeconfigs_backend = puppetdb
> reports = store, puppetdb
> 
> [agent]
> noop = true
> 
> The next script is from puppetdb.conf location is
> /etc/puppetlabs/puppet/puppetdb.conf
> 
> [main]
>  server_urls = https://puppetdb.company.com:8081 
> 
> 
> 
> The puppetdb config.ini file
> (/etc/puppetlabs/puppetdb/conf.d/config.ini) is as follows:
> 
> #logging-config = /etc/puppetlabs/puppetdb/logback.xml
> 
> #[command-processing]
> # How many command-processing threads to use, defaults to (CPUs / 2)
> # threads = 4
> 
> # How many threads can write to disk at once, defaults to min(CPUs / 2, 4)
> # concurrent-writes = 4
> 
> [global]
> vardir = /var/lib/puppetdb
> logging-config = /var/lib/puppetdb/logback.xml
> 
> [database]
> classname = org.postgresql.Driver
> subprotocol = postgresql
> subname = //localhost:8081/puppetdb
> 
> [puppetdb]
> certificate-whitelist = /path/to/file/containing/certnames
> disable-update-checking = false
> 
> The puppetdb jetty.ini file
> (/etc/puppetlabs/puppetdb/conf.d/jetty.ini) is as follows:
> 
> [jetty]
> # IP address or hostname to listen for clear-text HTTP. To avoid resolution
> # issues, IP addresses are recommended over hostnames.
> # Default is `localhost`.
> # host = 
> 
> # Port to listen on for clear-text HTTP.
> port = 8080
> 
> # The following are SSL specific settings. They can be configured
> # automatically with the tool `puppetdb ssl-setup`, which is normally
> # ran during package installation.
> 
> # IP address to listen on for HTTPS connections. Hostnames can also be used
> # but are not recommended to avoid DNS resolution issues. To listen on all
> # interfaces, use `0.0.0.0`.
> ssl-host = 0.0.0.0
> 
> # The port to listen on for HTTPS connections
> ssl-port = 8081
> 
> # Private key path
> ssl-key = /etc/puppetlabs/puppetdb/ssl/private.pem
> 
> # Public certificate path

[Puppet Users] PuppetDB - ERROR [p.p.config] No subname set in the "database" config`

2022-10-10 Thread Callum McCrorie
Hello,
I’m reaching out about an issue related to PuppetDB. I am hoping that
someone will be able to assist myself and my coworker in solving this
problem.

When I take a look inside the puppetdb log file the error that I am
seeing is `ERROR [p.p.config] No subname set in the "database"
config`. Root to the log file is - 
/var/log/puppetlabs/puppetdb/puppetdb.log.

If I try to start puppetdb service manually by running `systemctl
start puppetdb` I then receive the following error message:
`Job for puppetdb.service failed because the control process exited
with error code.
See "systemctl status puppetdb.service" and "journalctl -xe" for details.`

Following this when looking at `journalctl -xe` I can see the error message:
`-- The unit puppetdb.service has entered the 'failed' state with
result 'exit-code'
Oct 04 13:37:36 puppet systemd[1]: Failed to start puppetdb Service.
-- Subject: A start job for unit puppetdb.service has failed.'

I have also included in this the PuppetDB scripts and any related scripts.

The following script is for puppet.conf location is
/etc/puppetlabs/puppet/puppet.conf.

# This file can be used to override the default puppet settings.
# See the following links for more details on what settings are available:
# - https://puppet.com/docs/puppet/latest/config_important_settings.html
# - https://puppet.com/docs/puppet/latest/config_about_settings.html
# - https://puppet.com/docs/puppet/latest/config_file_main.html
# - https://puppet.com/docs/puppet/latest/configuration.html
[server]
vardir = /opt/puppetlabs/server/data/puppetserver
logdir = /var/log/puppetlabs/puppetserver
rundir = /var/run/puppetlabs/puppetserver
pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
codedir = /etc/puppetlabs/code

[master]
storeconfigs = true
storeconfigs_backend = puppetdb
reports = store, puppetdb

[agent]
noop = true

The next script is from puppetdb.conf location is
/etc/puppetlabs/puppet/puppetdb.conf

[main]
 server_urls = https://puppetdb.company.com:8081


The puppetdb config.ini file
(/etc/puppetlabs/puppetdb/conf.d/config.ini) is as follows:

#logging-config = /etc/puppetlabs/puppetdb/logback.xml

#[command-processing]
# How many command-processing threads to use, defaults to (CPUs / 2)
# threads = 4

# How many threads can write to disk at once, defaults to min(CPUs / 2, 4)
# concurrent-writes = 4

[global]
vardir = /var/lib/puppetdb
logging-config = /var/lib/puppetdb/logback.xml

[database]
classname = org.postgresql.Driver
subprotocol = postgresql
subname = //localhost:8081/puppetdb

[puppetdb]
certificate-whitelist = /path/to/file/containing/certnames
disable-update-checking = false

The puppetdb jetty.ini file
(/etc/puppetlabs/puppetdb/conf.d/jetty.ini) is as follows:

[jetty]
# IP address or hostname to listen for clear-text HTTP. To avoid resolution
# issues, IP addresses are recommended over hostnames.
# Default is `localhost`.
# host = 

# Port to listen on for clear-text HTTP.
port = 8080

# The following are SSL specific settings. They can be configured
# automatically with the tool `puppetdb ssl-setup`, which is normally
# ran during package installation.

# IP address to listen on for HTTPS connections. Hostnames can also be used
# but are not recommended to avoid DNS resolution issues. To listen on all
# interfaces, use `0.0.0.0`.
ssl-host = 0.0.0.0

# The port to listen on for HTTPS connections
ssl-port = 8081

# Private key path
ssl-key = /etc/puppetlabs/puppetdb/ssl/private.pem

# Public certificate path
ssl-cert = /etc/puppetlabs/puppetdb/ssl/public.pem

# Certificate authority path
ssl-ca-cert = /etc/puppetlabs/puppetdb/ssl/ca.pem

# Access logging configuration path. To turn off access logging
# comment out the line with `access-log-config=...`
access-log-config = /etc/puppetlabs/puppetdb/request-logging.xml
client-auth = want

The puppetdb auth.conf file
(/etc/puppetlabs/puppetdb/conf.d/auth.conf) is as follows:

authorization: {
version: 1
rules: [
{
# Allow unauthenticated access to the status service endpoint
match-request: {
path: "/status/v1/services"
type: path
method: get
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs status service - full"
},
{
match-request: {
path: "/status/v1/simple"
type: path
method: get
}
allow-unauthenticated: true
sort-order: 500
name: "puppetlabs status service - simple"
},
{
# Allow nodes to access the metrics service
# for puppetdb, the metrics service is the only
# service using the authentication service
match-request: {
path: "/metrics"
type: path
method: [get, post]
}
allow: "*"
sort-order: 500

Re: [Puppet Users] [PuppetDB] Error 500 'Failed to execute '/pdb/cmd/v1....'

2022-10-10 Thread Martin Alfke
Hi Nir,

Please check the puppetdb log file for further error investigation.
Usually this is located at /var/log/puppetlabs/puppetdb/puppetdb.log

Hth,
Martin


> On 30. Sep 2022, at 10:30, Nir Fishler  wrote:
> 
> Hello,
> 
> puppetserver version: 7.8.0  (CentOS 7) | hostname:  puppet-staging-srv
> puppet agent: 7.19
> puppetdb: 7.11.0-1focal (Ubuntu 20.04) | hostname: puppet-staging-srv-db
> Postgres: 12.12-0ubuntu0.20.04.1
> 
> Foreman is enabled on Puppetserver.
> Postgres is configured to work with SSL.
> 
> Getting the below error from ANY VM on the network whenever I try to sync 
> with Puppet master server.
> 
> Error message:
> Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
> Server Error: Failed to execute 
> '/pdb/cmd/v1?checksum=a0d1b67028ed455a4d8b15fd5fc846ca54d4c0a6=5=vm-ubuntu20=replace_facts=2022-09-30T07:47:13.621Z'
>  on at least 1 of the following 'server_urls': 
> https://puppet-staging-srv-db:8081
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
> 
> However, When I remove the configuration files(puppetdb.conf , values from 
> puppet.conf, routes.yaml) from the Puppet master $CONF dir, everything is 
> back to normal and sync works.
> 
> Connection between Puppet master and puppetdb and vice vesra:
> [root@puppet-staging-srv puppet] nc -zvw10 puppet-staging-srv-db 8081
> Ncat: Version 7.50 ( https://nmap.org/ncat )
> Ncat: Connected to 10.111.8.77:8081.
> 
> root@puppet-staging-srv-db:~# nc -zvw10 puppet-staging-srv 8140
> Connection to puppet-staging-srv 8140 port [tcp/puppet] succeeded!
> 
> PuppetDB website is UP and shows zero data on 'Active Nodes' and most of the 
> fields(see screenshot snap-1.png.)
> 
> Thanks in advanced!
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/af30e761-f765-4260-978e-b4817e42f3b8n%40googlegroups.com
>  
> .
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/DFD05FB5-DADB-49C1-A5A4-C901BDD293F8%40gmail.com.


[Puppet Users] PuppetDB with postgres

2021-07-17 Thread keyze...@gmail.com
Hi

just realised my puppetdb attached to pgsql is configured for latin1 

is it okay to stop all puppet services and then export , recreate the 
database to utf8 and then restart 

I'm getting these in my log
ERROR: character with byte sequence 0xe2 0x80 0x9c in encoding "UTF8" has 
no equivalent in encoding "LATIN1"


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f1415fb3-ed2b-4c27-b71b-b799b3cd791dn%40googlegroups.com.


[Puppet Users] puppetdb ssldir chown is breaking PuppetDB

2021-01-31 Thread comport3

It seems the puppet agent, when invoked by the service or manually, is 
resetting the permissions on the files in the puppetdb ssldir 
(/etc/puppetlabs/puppetdb/ssl/*.pem) from puppetdb:puppetdb to 
puppet:puppet AND the mode on the 
mode on the 'private.pem' file to 0640, which means the next time the 
puppetdb service attempts to start, it fails due to a lack of permission.

This only seems to have come up in the past week or so, as we've only just 
started observing it, and causing problems. We have a temporary workaround 
where we chown the files back to puppetdb, start PuppetDB and that's fine, 
but next puppet agent invocation causes the above issue.

Has anyone else observed this problem? Is it a bug?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/be8dffc3-c4cc-41b6-8c91-ad2182e7efd2n%40googlegroups.com.


[Puppet Users] puppetdb failover - implement ca self signed

2021-01-19 Thread Nerbolff
Hello everyone. for security reasons. we decided to get 2 puppetdb servers 
up and running. there will be a setup with *master* and *slave*.

We thought of using our load balancer to perform this operation. So we need 
a *cname* with a valid self-generated certificate. ie:  
 puppetdb.internet.net

 
Here's how I think I'm going to achieve it: 

   - I generated my puppetdb cert via the puppetca:

$ sudo puppetserver ca generate --certname puppetdb.internet.net
Successfully saved private key for puppetdb.internet.net to 
/etc/puppetlabs/puppet/ssl/private_keys/puppetdb.internet.net.pem
Successfully saved public key for puppetdb.internet.net to 
/etc/puppetlabs/puppet/ssl/public_keys/puppetdb.internet.net.pem
Successfully submitted certificate request for puppetdb.internet.net
Error:
Signed certificate puppetdb.internet.net could not be found on the CA
Successfully signed certificate request for puppetdb.internet.net
Successfully saved certificate for puppetdb.internet.net to 
/etc/puppetlabs/puppet/ssl/certs/puppetdb.internet.net.pem


Then I copied over the freshly selfsigned cert from puppetca to puppetDB.
 I changed the */etc/puppetlabs/puppetdb/conf.d/jetty.ini* like this : 

ssl-key = /etc/puppetlabs/puppet/ssl/private_keys/puppetdb.internet.net.pem
ssl-cert = /etc/puppetlabs/puppet/ssl/public_keys/puppetdb.internet.net.pem
ssl-ca-cert = /etc/puppetlabs/puppet/ssl/certs/puppetdb.internet.net.pem

restarting my puppetdb, I get an error about certification implementation.  
error is not clear. java errors

At the end,  my goal is to start puppetdb with the certificate 
*puppetdb.internet.net 
*loaded. then the puppetmaster didn't complain about the puppetca 
certificate. 

Does someone have any idea?
Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/163cae20-4e87-400a-8f95-fa51bb241aadn%40googlegroups.com.


[Puppet Users] puppetdb v7 test: no such file to load -- puppet/util/puppetdb

2020-12-08 Thread comport3

Whilst trying to test a new Puppet v7.0.0 master (which is OK) and 
PuppetDB, I get the following on PuppetDB:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: 
Internal Server Error: org.jruby.exceptions.LoadError: (LoadError) no such 
file to load -- puppet/util/puppetdb

Copying 'puppetdb.rb' to the path: 
'/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util' fixes this issue.

I'm using the latest version (from Forge) of Puppetserver and Puppetdb 
modules on Ubuntu 20.04.

Any idea what I'm doing wrong?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ec0a5f33-88cf-4b0e-866f-13747e8f0033n%40googlegroups.com.


Re: [Puppet Users] PuppetDB and PostgreSQL 12 errors

2020-09-18 Thread Zachary Kent
On Fri, Sep 18, 2020 at 6:29 AM Bob Negri  wrote:

> So 4 hrs might not be big enough? (Looks like the person who did the
> update did not check the documents.) Trying the new settings now.
>

Yea I don't think 4 hrs is long enough and would cause the behavior you're
seeing. In that case when gc fires after 4 hours there will be incoming
commands trying to recreate the table that gc is trying to drop. Then every
time the gc_interval passes the same thing will happen again causing the
errors you're seeing. If you set the *report_ttl* and *resource_events_ttl*
settings to over 24 hours this issue should go away. You'll still see some
of the *"resource_events_20200917z" does not exist *errors, but these
should only happen once a day when a new partition needs to be created.

I think our documentation for those two settings might be lacking with
regards to this issue. We added partitioning for reports and
resource_events recently and didn't mention the case you're describing in
the docs. We will make an update to the docs soon using this ticket:
PDB-4899  to track the
work. Thanks for bringing this up!



> On Thursday, September 17, 2020 at 6:27:29 PM UTC-5 zachar...@puppet.com
> wrote:
>
>> On Thu, Sep 17, 2020 at 8:12 AM Bob Negri  wrote:
>>
>>> We recently updated our PuppetDB servers to PuppetDB 6.12.0 and
>>> PostgreSQL 12.
>>> Started getting these errors:
>>>
>>> ERROR:  relation "resource_events_20200917z" does not exist at character
>>> 13
>>> ERROR:  relation "resource_events_20200917z" already exists
>>> ERROR:  deadlock detected
>>> ERROR:  could not serialize access due to concurrent delete
>>>
>>> Not sure if it is a PuppetDB setting or a Postgresql issue. Has anyone
>>> else seen this?
>>>
>>> Here is more detail:
>>>
>>> 2020-09-17 14:32:49.515 UTC [3941] ERROR:  relation
>>> "resource_events_20200917z" does not exist at character 13
>>> 2020-09-17 14:32:49.515 UTC [3941] QUERY:  INSERT INTO
>>> resource_events_20200917Z SELECT ($1).*
>>> 2020-09-17 14:32:49.515 UTC [3941] CONTEXT:  PL/pgSQL function
>>> resource_events_insert_trigger() line 8 at EXECUTE
>>> 2020-09-17 14:32:49.515 UTC [3941] STATEMENT:  INSERT INTO
>>> resource_events ( new_value, property, name, file, report_id, event_hash,
>>> old_value, containing_class, certname_id, line, resource_type, status,
>>> resource_title, timestamp, containment_path, message ) VALUES ( $1, $2, $3,
>>> $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16 )
>>> RETURNING *
>>> 2020-09-17 14:32:49.538 UTC [3937] ERROR:  relation
>>> "resource_events_20200917z" already exists
>>> 2020-09-17 14:32:49.538 UTC [3937] STATEMENT:  CREATE TABLE IF NOT
>>> EXISTS resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH
>>> TIME ZONE '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE
>>> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
>>> 2020-09-17 14:32:49.538 UTC [3945] ERROR:  relation
>>> "resource_events_20200917z" already exists
>>> 2020-09-17 14:32:49.538 UTC [3945] STATEMENT:  CREATE TABLE IF NOT
>>> EXISTS resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH
>>> TIME ZONE '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE
>>> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
>>> 2020-09-17 14:32:49.538 UTC [3941] ERROR:  relation
>>> "resource_events_20200917z" already exists
>>> 2020-09-17 14:32:49.538 UTC [3941] STATEMENT:  CREATE TABLE IF NOT
>>> EXISTS resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH
>>> TIME ZONE '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE
>>> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
>>> 2020-09-17 14:33:27.917 UTC [2875] ERROR:  deadlock detected
>>> 2020-09-17 14:33:27.917 UTC [2875] DETAIL:  Process 2875 waits for
>>> AccessExclusiveLock on relation 7883116 of database 16385; blocked by
>>> process 3945.
>>> Process 3945 waits for RowExclusiveLock on relation 7883178 of
>>> database 16385; blocked by process 2875.
>>> Process 2875: drop table if exists reports_20200917z cascade
>>> Process 3945: INSERT INTO resource_events ( new_value, property,
>>> name, file, report_id, event_hash, old_value, containing_class,
>>> certname_id, line, resource_type, status, resource_title, timestamp,
>>> containment_path, message ) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9,
>>> $10, $11, $12, $13, $14, $15, $16 )
>>> RETURNING *
>>>
>>> From the logs above it looks like the gc process in PuppetDB represented
>> by the Postgres process 2875 is trying to drop the reports_20200917z
>> partition while other transactions are trying to insert into
>> resource_events partitions for the same day. PuppetDB handles
>> partition creation by first trying to insert a row and then creating the
>> partition for a given day if one doesn't yet exist.
>>
>> I'm wondering if your install has the *report_ttl* or
>> *resource_events_tt*l described in the 

Re: [Puppet Users] PuppetDB and PostgreSQL 12 errors

2020-09-18 Thread Bob Negri
So 4 hrs might not be big enough? (Looks like the person who did the update 
did not check the documents.) Trying the new settings now.

On Thursday, September 17, 2020 at 6:27:29 PM UTC-5 zachar...@puppet.com 
wrote:

> On Thu, Sep 17, 2020 at 8:12 AM Bob Negri  wrote:
>
>> We recently updated our PuppetDB servers to PuppetDB 6.12.0 and 
>> PostgreSQL 12.
>> Started getting these errors:
>>
>> ERROR:  relation "resource_events_20200917z" does not exist at character 
>> 13
>> ERROR:  relation "resource_events_20200917z" already exists
>> ERROR:  deadlock detected
>> ERROR:  could not serialize access due to concurrent delete
>>
>> Not sure if it is a PuppetDB setting or a Postgresql issue. Has anyone 
>> else seen this?
>>
>> Here is more detail:
>>
>> 2020-09-17 14:32:49.515 UTC [3941] ERROR:  relation 
>> "resource_events_20200917z" does not exist at character 13
>> 2020-09-17 14:32:49.515 UTC [3941] QUERY:  INSERT INTO 
>> resource_events_20200917Z SELECT ($1).*
>> 2020-09-17 14:32:49.515 UTC [3941] CONTEXT:  PL/pgSQL function 
>> resource_events_insert_trigger() line 8 at EXECUTE
>> 2020-09-17 14:32:49.515 UTC [3941] STATEMENT:  INSERT INTO 
>> resource_events ( new_value, property, name, file, report_id, event_hash, 
>> old_value, containing_class, certname_id, line, resource_type, status, 
>> resource_title, timestamp, containment_path, message ) VALUES ( $1, $2, $3, 
>> $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14, $15, $16 )
>> RETURNING *
>> 2020-09-17 14:32:49.538 UTC [3937] ERROR:  relation 
>> "resource_events_20200917z" already exists
>> 2020-09-17 14:32:49.538 UTC [3937] STATEMENT:  CREATE TABLE IF NOT EXISTS 
>> resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE 
>> '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE 
>> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
>> 2020-09-17 14:32:49.538 UTC [3945] ERROR:  relation 
>> "resource_events_20200917z" already exists
>> 2020-09-17 14:32:49.538 UTC [3945] STATEMENT:  CREATE TABLE IF NOT EXISTS 
>> resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE 
>> '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE 
>> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
>> 2020-09-17 14:32:49.538 UTC [3941] ERROR:  relation 
>> "resource_events_20200917z" already exists
>> 2020-09-17 14:32:49.538 UTC [3941] STATEMENT:  CREATE TABLE IF NOT EXISTS 
>> resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE 
>> '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE 
>> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
>> 2020-09-17 14:33:27.917 UTC [2875] ERROR:  deadlock detected
>> 2020-09-17 14:33:27.917 UTC [2875] DETAIL:  Process 2875 waits for 
>> AccessExclusiveLock on relation 7883116 of database 16385; blocked by 
>> process 3945.
>> Process 3945 waits for RowExclusiveLock on relation 7883178 of 
>> database 16385; blocked by process 2875.
>> Process 2875: drop table if exists reports_20200917z cascade
>> Process 3945: INSERT INTO resource_events ( new_value, property, 
>> name, file, report_id, event_hash, old_value, containing_class, 
>> certname_id, line, resource_type, status, resource_title, timestamp, 
>> containment_path, message ) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9, 
>> $10, $11, $12, $13, $14, $15, $16 )
>> RETURNING *
>>
>> From the logs above it looks like the gc process in PuppetDB represented 
> by the Postgres process 2875 is trying to drop the reports_20200917z 
> partition while other transactions are trying to insert into 
> resource_events partitions for the same day. PuppetDB handles 
> partition creation by first trying to insert a row and then creating the 
> partition for a given day if one doesn't yet exist.  
>
> I'm wondering if your install has the *report_ttl* or *resource_events_tt*l 
> described in the PuppetDB config docs 
>  
> set 
> to a value that's less than one day. If this were the case it's possible 
> that the gc process is trying to drop partitions for the same day that 
> incoming commands are trying to create them for, causing conflicts. 
> Normally you could expect to see a couple of the *"resource_events_20200917z" 
> does not exist *errors per day around the same time for both the 
> *reports_* and *resource_events_* partitions. If your ttl 
> settings aren't set to less than a day and you're seeing these errors more 
> regularly than daily please let us know. 
>   
>
>>
>> 2020-09-17 14:34:47.339 UTC [2875] ERROR:  could not serialize access due 
>> to concurrent delete
>> 2020-09-17 14:34:47.339 UTC [2875] STATEMENT:  delete from fact_paths fp  
>> where not exists (select 1 from tmp_live_paths  where 
>> tmp_live_paths.path = fp.path)
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" 

Re: [Puppet Users] PuppetDB and PostgreSQL 12 errors

2020-09-17 Thread Zachary Kent
On Thu, Sep 17, 2020 at 8:12 AM Bob Negri  wrote:

> We recently updated our PuppetDB servers to PuppetDB 6.12.0 and PostgreSQL
> 12.
> Started getting these errors:
>
> ERROR:  relation "resource_events_20200917z" does not exist at character 13
> ERROR:  relation "resource_events_20200917z" already exists
> ERROR:  deadlock detected
> ERROR:  could not serialize access due to concurrent delete
>
> Not sure if it is a PuppetDB setting or a Postgresql issue. Has anyone
> else seen this?
>
> Here is more detail:
>
> 2020-09-17 14:32:49.515 UTC [3941] ERROR:  relation
> "resource_events_20200917z" does not exist at character 13
> 2020-09-17 14:32:49.515 UTC [3941] QUERY:  INSERT INTO
> resource_events_20200917Z SELECT ($1).*
> 2020-09-17 14:32:49.515 UTC [3941] CONTEXT:  PL/pgSQL function
> resource_events_insert_trigger() line 8 at EXECUTE
> 2020-09-17 14:32:49.515 UTC [3941] STATEMENT:  INSERT INTO resource_events
> ( new_value, property, name, file, report_id, event_hash, old_value,
> containing_class, certname_id, line, resource_type, status, resource_title,
> timestamp, containment_path, message ) VALUES ( $1, $2, $3, $4, $5, $6, $7,
> $8, $9, $10, $11, $12, $13, $14, $15, $16 )
> RETURNING *
> 2020-09-17 14:32:49.538 UTC [3937] ERROR:  relation
> "resource_events_20200917z" already exists
> 2020-09-17 14:32:49.538 UTC [3937] STATEMENT:  CREATE TABLE IF NOT EXISTS
> resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE
> '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE
> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
> 2020-09-17 14:32:49.538 UTC [3945] ERROR:  relation
> "resource_events_20200917z" already exists
> 2020-09-17 14:32:49.538 UTC [3945] STATEMENT:  CREATE TABLE IF NOT EXISTS
> resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE
> '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE
> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
> 2020-09-17 14:32:49.538 UTC [3941] ERROR:  relation
> "resource_events_20200917z" already exists
> 2020-09-17 14:32:49.538 UTC [3941] STATEMENT:  CREATE TABLE IF NOT EXISTS
> resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE
> '2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE
> '2020-09-18T00:00:00Z' )) INHERITS (resource_events)
> 2020-09-17 14:33:27.917 UTC [2875] ERROR:  deadlock detected
> 2020-09-17 14:33:27.917 UTC [2875] DETAIL:  Process 2875 waits for
> AccessExclusiveLock on relation 7883116 of database 16385; blocked by
> process 3945.
> Process 3945 waits for RowExclusiveLock on relation 7883178 of
> database 16385; blocked by process 2875.
> Process 2875: drop table if exists reports_20200917z cascade
> Process 3945: INSERT INTO resource_events ( new_value, property,
> name, file, report_id, event_hash, old_value, containing_class,
> certname_id, line, resource_type, status, resource_title, timestamp,
> containment_path, message ) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9,
> $10, $11, $12, $13, $14, $15, $16 )
> RETURNING *
>
> From the logs above it looks like the gc process in PuppetDB represented
by the Postgres process 2875 is trying to drop the reports_20200917z
partition while other transactions are trying to insert into
resource_events partitions for the same day. PuppetDB handles
partition creation by first trying to insert a row and then creating the
partition for a given day if one doesn't yet exist.

I'm wondering if your install has the *report_ttl* or *resource_events_tt*l
described in the PuppetDB config docs

set
to a value that's less than one day. If this were the case it's possible
that the gc process is trying to drop partitions for the same day that
incoming commands are trying to create them for, causing conflicts.
Normally you could expect to see a couple of the *"resource_events_20200917z"
does not exist *errors per day around the same time for both the
*reports_* and *resource_events_* partitions. If your ttl
settings aren't set to less than a day and you're seeing these errors more
regularly than daily please let us know.


>
> 2020-09-17 14:34:47.339 UTC [2875] ERROR:  could not serialize access due
> to concurrent delete
> 2020-09-17 14:34:47.339 UTC [2875] STATEMENT:  delete from fact_paths fp
> where not exists (select 1 from tmp_live_paths  where
> tmp_live_paths.path = fp.path)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/6f23bccd-22cd-48dd-acd8-e8e0247440fdn%40googlegroups.com
> 

[Puppet Users] PuppetDB and PostgreSQL 12 errors

2020-09-17 Thread Bob Negri
We recently updated our PuppetDB servers to PuppetDB 6.12.0 and PostgreSQL 
12.
Started getting these errors:

ERROR:  relation "resource_events_20200917z" does not exist at character 13
ERROR:  relation "resource_events_20200917z" already exists
ERROR:  deadlock detected
ERROR:  could not serialize access due to concurrent delete

Not sure if it is a PuppetDB setting or a Postgresql issue. Has anyone else 
seen this?

Here is more detail:

2020-09-17 14:32:49.515 UTC [3941] ERROR:  relation 
"resource_events_20200917z" does not exist at character 13
2020-09-17 14:32:49.515 UTC [3941] QUERY:  INSERT INTO 
resource_events_20200917Z SELECT ($1).*
2020-09-17 14:32:49.515 UTC [3941] CONTEXT:  PL/pgSQL function 
resource_events_insert_trigger() line 8 at EXECUTE
2020-09-17 14:32:49.515 UTC [3941] STATEMENT:  INSERT INTO resource_events 
( new_value, property, name, file, report_id, event_hash, old_value, 
containing_class, certname_id, line, resource_type, status, resource_title, 
timestamp, containment_path, message ) VALUES ( $1, $2, $3, $4, $5, $6, $7, 
$8, $9, $10, $11, $12, $13, $14, $15, $16 )
RETURNING *
2020-09-17 14:32:49.538 UTC [3937] ERROR:  relation 
"resource_events_20200917z" already exists
2020-09-17 14:32:49.538 UTC [3937] STATEMENT:  CREATE TABLE IF NOT EXISTS 
resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE 
'2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE 
'2020-09-18T00:00:00Z' )) INHERITS (resource_events)
2020-09-17 14:32:49.538 UTC [3945] ERROR:  relation 
"resource_events_20200917z" already exists
2020-09-17 14:32:49.538 UTC [3945] STATEMENT:  CREATE TABLE IF NOT EXISTS 
resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE 
'2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE 
'2020-09-18T00:00:00Z' )) INHERITS (resource_events)
2020-09-17 14:32:49.538 UTC [3941] ERROR:  relation 
"resource_events_20200917z" already exists
2020-09-17 14:32:49.538 UTC [3941] STATEMENT:  CREATE TABLE IF NOT EXISTS 
resource_events_20200917Z (CHECK ( "timestamp" >= TIMESTAMP WITH TIME ZONE 
'2020-09-17T00:00:00Z' AND "timestamp" < TIMESTAMP WITH TIME ZONE 
'2020-09-18T00:00:00Z' )) INHERITS (resource_events)
2020-09-17 14:33:27.917 UTC [2875] ERROR:  deadlock detected
2020-09-17 14:33:27.917 UTC [2875] DETAIL:  Process 2875 waits for 
AccessExclusiveLock on relation 7883116 of database 16385; blocked by 
process 3945.
Process 3945 waits for RowExclusiveLock on relation 7883178 of 
database 16385; blocked by process 2875.
Process 2875: drop table if exists reports_20200917z cascade
Process 3945: INSERT INTO resource_events ( new_value, property, 
name, file, report_id, event_hash, old_value, containing_class, 
certname_id, line, resource_type, status, resource_title, timestamp, 
containment_path, message ) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9, 
$10, $11, $12, $13, $14, $15, $16 )
RETURNING *


2020-09-17 14:34:47.339 UTC [2875] ERROR:  could not serialize access due 
to concurrent delete
2020-09-17 14:34:47.339 UTC [2875] STATEMENT:  delete from fact_paths fp  
where not exists (select 1 from tmp_live_paths  where 
tmp_live_paths.path = fp.path)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6f23bccd-22cd-48dd-acd8-e8e0247440fdn%40googlegroups.com.


[Puppet Users] PuppetDB 6.12.0 and Postgresql 12: ERROR: relation "reports_20200916z" does not exist at character 13

2020-09-17 Thread Bob Negri
Has anyone see errors like this one? We recently upgraded from Postgresql 
9.6 to Postgresql 12 and from PuppetDB 6.7 (I think as I did not do it) to 
6.12.0.

2020-09-16 19:24:15.997 UTC [35203] ERROR:  relation "reports_20200916z" 
does not exist at character 13
2020-09-16 19:24:15.997 UTC [35203] STATEMENT:  INSERT INTO 
reports_20200916Z ( status_id, environment_id, catalog_uuid, receive_time, 
hash, transaction_uuid, puppet_version, noop, logs, report_format, 
start_time, producer_timestamp, cached_catalog_status, end_time, 
producer_id, report_type, configuration_version, code_id, noop_pending, 
certname, metrics, job_id ) VALUES ( $1, $2, $3, $4, $5, $6, $7, $8, $9, 
$10, $11, $12, $13, $14, $15, $16, $17, $18, $19, $20, $21, $22 )
   RETURNING *

Thanks,
Bob


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/dc246702-14b4-4716-b834-76424c7345aan%40googlegroups.com.


Re: [Puppet Users] Puppetdb upgrade - perfomance dashboard blank (mostly)

2020-08-20 Thread Austin Blatt

Hi,

This is the manifestation of a bug in PuppetDB (PDB-4855 
). We just merged a fix 
for that bug and it'll be fixed in the next release.


On 8/20/20 1:08 PM, Dave Beedle wrote:
After updating puppetdb from v6.7.3 to 6.11.3, the puppetdb dashboard 
connects and begins to show data but stops after showing the version 
number.  The version number is correct.  All else seems to work.


In the log there is:
2020-08-20T20:04:49.049Z WARN  [o.e.j.s.HttpChannel] /pdb/dashboard/data
java.lang.ClassCastException: class java.lang.String cannot be cast to 
class java.lang.Number (java.lang.String and java.lang.Number are in 
module java.base of loader 'bootstrap')


Prior to updating puppetdb, java was also updated to 11.  The 
dashboard displayed properly.


Would anyone have any tips and addressing this issue?
--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/44d8402e-5dad-47d4-9289-24d771140fa2n%40googlegroups.com 
.


--
Austin Blatt
Developer, Puppet

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/a4b93965-e73f-d7ca-dd0c-4bc7c6893fb1%40puppet.com.


[Puppet Users] Puppetdb upgrade - perfomance dashboard blank (mostly)

2020-08-20 Thread Dave Beedle
After updating puppetdb from v6.7.3 to 6.11.3, the puppetdb dashboard 
connects and begins to show data but stops after showing the version 
number.  The version number is correct.  All else seems to work.

In the log there is:
2020-08-20T20:04:49.049Z WARN  [o.e.j.s.HttpChannel] /pdb/dashboard/data
java.lang.ClassCastException: class java.lang.String cannot be cast to 
class java.lang.Number (java.lang.String and java.lang.Number are in module 
java.base of loader 'bootstrap')

Prior to updating puppetdb, java was also updated to 11.  The dashboard 
displayed properly.

Would anyone have any tips and addressing this issue?  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/44d8402e-5dad-47d4-9289-24d771140fa2n%40googlegroups.com.


Re: [Puppet Users] PuppetDB is broken after Debian upgrade to Stretch

2020-08-20 Thread Austin Blatt
I'm unable to reproduce this, can you share the example CURL command you
are using that results in this error?

On Wed, Aug 19, 2020 at 9:23 AM Eugene Bolshakoff <
mercurius.lang...@gmail.com> wrote:

>
> Hello,
>
> PuppetDB is partially broken after we upgrade Debian from Jessie to
> Stretch.
> PuppetDB version has been upgraded from 5.2.9 to 5.2.18. We used "apt-get
> dist-upgrade" command, no manual setups.
>
> Puppet master works fine with Puppetdb. But, if I try to use API via CURL,
> I got:
>
> Problem accessing /pdb/query/v4/resources. Reason:
> Server ErrorCaused
> by:clojure.lang.ExceptionInfo: Input to paged-sql does not match
> schema: [(named (not (instance? java.lang.String a-honeysql.types.SqlRaw))
> sql) nil] {:type :schema.core/error, :schema [#schema.core.One{:schema
> java.lang.String, :optional? false, :name sql} #schema.core.One{:schema
> Any, :optional? false, :name arg1}], :value [#sql/raw  ( SELECT
> reports.corrective_change AS latest_report_corrective_change,
> certnames.deactivated AS deactivated, certnames.expired AS expired,
> reports_environment.environment AS report_environment, certnames.certname
> AS certname, fs.timestamp AS facts_timestamp, facts_environment.environment
> AS facts_environment, reports.cached_catalog_status AS
> cached_catalog_status, report_statuses.status AS latest_report_status,
> encode(reports.hash::bytea, hex) AS latest_report_hash,
> catalogs.timestamp AS catalog_timestamp, reports.noop_pending AS
> latest_report_noop_pending, reports.end_time AS report_timestamp,
> reports.noop AS latest_report_noop, catalog_environment.environment AS
> catalog_environment, reports.job_id AS latest_report_job_id FROM certnames
> LEFT JOIN catalogs ON catalogs.certname = certnames.certname LEFT JOIN
> factsets fs ON certnames.certname = fs.certname LEFT JOIN reports ON
> (certnames.certname = reports.certname AND certnames.latest_report_id =
> reports.id) LEFT JOIN environments catalog_environment ON
> catalog_environment.id = catalogs.environment_id LEFT JOIN
> report_statuses ON reports.status_id = report_statuses.id LEFT JOIN
> environments facts_environment ON facts_environment.id =
> fs.environment_id LEFT JOIN environments reports_environment ON
> reports_environment.id = reports.environment_id WHERE
> (((certnames.certname) in (SELECT certname FROM  ( (SELECT
> certnames.certname AS certname FROM factsets fs LEFT JOIN environments ON
> fs.environment_id = environments.id LEFT JOIN producers ON fs.producer_id
> = producers.id LEFT JOIN certnames ON fs.certname = certnames.certname
> WHERE (fs.stable||fs.volatile) @ ?) )  sub)) AND ((certnames.certname)
> in (SELECT certname FROM  ( (SELECT active_nodes.certname AS certname FROM
> active_nodes) )  sub))) )  {:node-purge-ttl
> #object[org.joda.time.Period 0x3484bd4a P14D], :limit nil,
> :offset nil, :order_by ()}], :error [(named (not (instance?
> java.lang.String a-honeysql.types.SqlRaw)) sql) nil]}
> at
> puppetlabs.puppetdb.jdbc$eval28778$paged_sql__28783.invoke(jdbc.clj:389)
> at
> puppetlabs.puppetdb.query_eng.engine$compile_user_query__GT_sql.invokeStatic(engine.clj:2429)
> at
> puppetlabs.puppetdb.query_eng.engine$compile_user_query__GT_sql.doInvoke(engine.clj:2410)
> at clojure.lang.RestFn.invoke(RestFn.java:442)
> at
> puppetlabs.puppetdb.query_eng$query__GT_sql.invokeStatic(query_eng.clj:115)
> at
> puppetlabs.puppetdb.query_eng$query__GT_sql.invoke(query_eng.clj:88)
> at
> puppetlabs.puppetdb.query_eng$eval35521$produce_streaming_body__35526$fn__35527$fn__35530.invoke(query_eng.clj:204)
> at
> puppetlabs.puppetdb.jdbc$with_transacted_connection_fn$fn__28935$fn__28936.invoke(jdbc.clj:514)
> at
> clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:628)
> at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:598)
> at
> puppetlabs.puppetdb.jdbc$with_transacted_connection_fn$fn__28935.invoke(jdbc.clj:513)
> at
> puppetlabs.puppetdb.jdbc$eval28909$retry_sql_STAR___28914$fn__28915$fn__28916.invoke(jdbc.clj:485)
> at
> puppetlabs.puppetdb.jdbc$eval28909$retry_sql_STAR___28914$fn__28915.invoke(jdbc.clj:484)
> at
> puppetlabs.puppetdb.jdbc$eval28909$retry_sql_STAR___28914.invoke(jdbc.clj:475)
> at
> puppetlabs.puppetdb.jdbc$with_transacted_connection_fn.invokeStatic(jdbc.clj:511)
> at
> puppetlabs.puppetdb.jdbc$with_transacted_connection_fn.invoke(jdbc.clj:500)
> at
> puppetlabs.puppetdb.query_eng$eval35521$produce_streaming_body__35526$fn__35527.invoke(query_eng.clj:200)
> at
> puppetlabs.puppetdb.query_eng$eval35521$produce_streaming_body__35526.invoke(query_eng.clj:185)
> at
> puppetlabs.puppetdb.http.query$query_handler$fn__38938.invoke(query.clj:383)
> at clojure.core$comp$fn__4727.invoke(core.clj:2460)
> at clojure.core$comp$fn__4727.invoke(core.clj:2460)
> at 

[Puppet Users] Puppetdb is broken after update

2020-08-19 Thread Eugene Bolshakoff
We updated Debian Jessie to Stretch and Puppetdb from 5.2.9 to 5.2.18. 
PostgreSQL version remains 9.6 (with a small minor update).
After update PuppetDB is partially broken. Puppet works fine with it, but 
if I try to use API, I get an error:

HTTP ERROR 500
Problem accessing /pdb/query/v4/resources. Reason:
Server ErrorCaused 
by:clojure.lang.ExceptionInfo: Input to paged-sql does not match 
schema: [(named (not (instance? java.lang.String a-honeysql.types.SqlRaw)) 
sql) nil] {:type :schema.core/error, :schema [#schema.core.One{:schema 
java.lang.String, :optional? false, :name sql} #schema.core.One{:schema 
Any, :optional? false, :name arg1}], :value [#sql/raw  ( SELECT 
reports.corrective_change AS latest_report_corrective_change, 
certnames.deactivated AS deactivated, certnames.expired AS expired, 
reports_environment.environment AS report_environment, certnames.certname 
AS certname, fs.timestamp AS facts_timestamp, facts_environment.environment 
AS facts_environment, reports.cached_catalog_status AS 
cached_catalog_status, report_statuses.status AS latest_report_status, 
encode(reports.hash::bytea, hex) AS latest_report_hash, 
catalogs.timestamp AS catalog_timestamp, reports.noop_pending AS 
latest_report_noop_pending, reports.end_time AS report_timestamp, 
reports.noop AS latest_report_noop, catalog_environment.environment AS 
catalog_environment, reports.job_id AS latest_report_job_id FROM certnames 
LEFT JOIN catalogs ON catalogs.certname = certnames.certname LEFT JOIN 
factsets fs ON certnames.certname = fs.certname LEFT JOIN reports ON 
(certnames.certname = reports.certname AND certnames.latest_report_id = 
reports.id) LEFT JOIN environments catalog_environment ON 
catalog_environment.id = catalogs.environment_id LEFT JOIN report_statuses 
ON reports.status_id = report_statuses.id LEFT JOIN environments 
facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN 
environments reports_environment ON reports_environment.id = 
reports.environment_id WHERE (((certnames.certname) in (SELECT certname 
FROM  ( (SELECT certnames.certname AS certname FROM factsets fs LEFT JOIN 
environments ON fs.environment_id = environments.id LEFT JOIN producers ON 
fs.producer_id = producers.id LEFT JOIN certnames ON fs.certname = 
certnames.certname WHERE (fs.stable||fs.volatile) @ ?) )  sub)) AND 
((certnames.certname) in (SELECT certname FROM  ( (SELECT 
active_nodes.certname AS certname FROM active_nodes) )  sub))) )  
{:node-purge-ttl #object[org.joda.time.Period 0x3484bd4a P14D], 
:limit nil, :offset nil, :order_by ()}], :error [(named (not (instance? 
java.lang.String a-honeysql.types.SqlRaw)) sql) nil]}

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2c1337ca-7586-4e20-9f27-a849e5785889n%40googlegroups.com.


[Puppet Users] PuppetDB is broken after Debian upgrade to Stretch

2020-08-19 Thread Eugene Bolshakoff

Hello,

PuppetDB is partially broken after we upgrade Debian from Jessie to Stretch.
PuppetDB version has been upgraded from 5.2.9 to 5.2.18. We used "apt-get 
dist-upgrade" command, no manual setups.

Puppet master works fine with Puppetdb. But, if I try to use API via CURL, 
I got:

Problem accessing /pdb/query/v4/resources. Reason:
Server ErrorCaused 
by:clojure.lang.ExceptionInfo: Input to paged-sql does not match 
schema: [(named (not (instance? java.lang.String a-honeysql.types.SqlRaw)) 
sql) nil] {:type :schema.core/error, :schema [#schema.core.One{:schema 
java.lang.String, :optional? false, :name sql} #schema.core.One{:schema 
Any, :optional? false, :name arg1}], :value [#sql/raw  ( SELECT 
reports.corrective_change AS latest_report_corrective_change, 
certnames.deactivated AS deactivated, certnames.expired AS expired, 
reports_environment.environment AS report_environment, certnames.certname 
AS certname, fs.timestamp AS facts_timestamp, facts_environment.environment 
AS facts_environment, reports.cached_catalog_status AS 
cached_catalog_status, report_statuses.status AS latest_report_status, 
encode(reports.hash::bytea, hex) AS latest_report_hash, 
catalogs.timestamp AS catalog_timestamp, reports.noop_pending AS 
latest_report_noop_pending, reports.end_time AS report_timestamp, 
reports.noop AS latest_report_noop, catalog_environment.environment AS 
catalog_environment, reports.job_id AS latest_report_job_id FROM certnames 
LEFT JOIN catalogs ON catalogs.certname = certnames.certname LEFT JOIN 
factsets fs ON certnames.certname = fs.certname LEFT JOIN reports ON 
(certnames.certname = reports.certname AND certnames.latest_report_id = 
reports.id) LEFT JOIN environments catalog_environment ON 
catalog_environment.id = catalogs.environment_id LEFT JOIN report_statuses 
ON reports.status_id = report_statuses.id LEFT JOIN environments 
facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN 
environments reports_environment ON reports_environment.id = 
reports.environment_id WHERE (((certnames.certname) in (SELECT certname 
FROM  ( (SELECT certnames.certname AS certname FROM factsets fs LEFT JOIN 
environments ON fs.environment_id = environments.id LEFT JOIN producers ON 
fs.producer_id = producers.id LEFT JOIN certnames ON fs.certname = 
certnames.certname WHERE (fs.stable||fs.volatile) @ ?) )  sub)) AND 
((certnames.certname) in (SELECT certname FROM  ( (SELECT 
active_nodes.certname AS certname FROM active_nodes) )  sub))) )  
{:node-purge-ttl #object[org.joda.time.Period 0x3484bd4a P14D], 
:limit nil, :offset nil, :order_by ()}], :error [(named (not (instance? 
java.lang.String a-honeysql.types.SqlRaw)) sql) nil]}
at 
puppetlabs.puppetdb.jdbc$eval28778$paged_sql__28783.invoke(jdbc.clj:389)
at 
puppetlabs.puppetdb.query_eng.engine$compile_user_query__GT_sql.invokeStatic(engine.clj:2429)
at 
puppetlabs.puppetdb.query_eng.engine$compile_user_query__GT_sql.doInvoke(engine.clj:2410)
at clojure.lang.RestFn.invoke(RestFn.java:442)
at 
puppetlabs.puppetdb.query_eng$query__GT_sql.invokeStatic(query_eng.clj:115)
at 
puppetlabs.puppetdb.query_eng$query__GT_sql.invoke(query_eng.clj:88)
at 
puppetlabs.puppetdb.query_eng$eval35521$produce_streaming_body__35526$fn__35527$fn__35530.invoke(query_eng.clj:204)
at 
puppetlabs.puppetdb.jdbc$with_transacted_connection_fn$fn__28935$fn__28936.invoke(jdbc.clj:514)
at clojure.java.jdbc$db_transaction_STAR_.invokeStatic(jdbc.clj:628)
at clojure.java.jdbc$db_transaction_STAR_.invoke(jdbc.clj:598)
at 
puppetlabs.puppetdb.jdbc$with_transacted_connection_fn$fn__28935.invoke(jdbc.clj:513)
at 
puppetlabs.puppetdb.jdbc$eval28909$retry_sql_STAR___28914$fn__28915$fn__28916.invoke(jdbc.clj:485)
at 
puppetlabs.puppetdb.jdbc$eval28909$retry_sql_STAR___28914$fn__28915.invoke(jdbc.clj:484)
at 
puppetlabs.puppetdb.jdbc$eval28909$retry_sql_STAR___28914.invoke(jdbc.clj:475)
at 
puppetlabs.puppetdb.jdbc$with_transacted_connection_fn.invokeStatic(jdbc.clj:511)
at 
puppetlabs.puppetdb.jdbc$with_transacted_connection_fn.invoke(jdbc.clj:500)
at 
puppetlabs.puppetdb.query_eng$eval35521$produce_streaming_body__35526$fn__35527.invoke(query_eng.clj:200)
at 
puppetlabs.puppetdb.query_eng$eval35521$produce_streaming_body__35526.invoke(query_eng.clj:185)
at 
puppetlabs.puppetdb.http.query$query_handler$fn__38938.invoke(query.clj:383)
at clojure.core$comp$fn__4727.invoke(core.clj:2460)
at clojure.core$comp$fn__4727.invoke(core.clj:2460)
at compojure.response$eval22875$fn__22876.invoke(response.clj:33)
at 
compojure.response$eval22830$fn__22831$G__22821__22838.invoke(response.clj:6)
at 
puppetlabs.puppetdb.http.handlers$eval39182$resources_routes__39187$fn__39188$fn__39189.invoke(handlers.clj:201)
at 
puppetlabs.puppetdb.http.query$extract_query$fn__38921.invoke(query.clj:315)

Re: [Puppet Users] Puppetdb and postgresql module: How to manage Postgresql but NOT manage Postgresql REPO using Hiera?

2020-07-03 Thread Devminded
Hi Martin.

I ended up with wrapping everything in my own profile classes and 
controlling it from there since I need to setup certs, auth, etc. anyway.

Thanks.

Den lördag 13 juni 2020 kl. 16:43:50 UTC+2 skrev Martin Alfke:
>
>
> postgresql::globals::manage_package_repo: false 
> postgresql::globals::version: '9.6', 
>
> > On 12. Jun 2020, at 17:40, Devminded > 
> wrote: 
> > 
> > Hi. 
> > 
> > I am trying to disable the managing of the Postgresql repo using Hiera 
> when using the puppetlabs/postgresql module. I have tried every Hiera 
> combination I can think of (from reading the docs/code) but nothing works. 
> > • puppetdb::database::postgresql::manage_package_repo: false 
> > • puppetdb::globals::manage_package_repo: false 
> > • postgresql::globals::manage_package_repo: false 
> > It still adds the /etc/apt/sources.list.d/apt.postgresql.org.list which 
> won't work since we are using our own Aptly mirror and servers cannot 
> directly communicate with the internet, and so the apt update fails and the 
> entire puppet agent run fails with it. 
> > 
> > How do I disable the management of 
> /etc/apt/sources.list.d/apt.postgresql.org.list using Hiera? 
> > 
> > System: 
> > • OS: Ubuntu 16.04 and 20.04 
> > • puppetserver version: 6.12.0 
> > • puppet-version: 6.16.0 
> > • mod 'puppetlabs/postgresql', '6.5.0' 
> > • mod 'puppetlabs/puppetdb', '7.4.0' 
> > • mod 'puppetlabs/stdlib', '6.3.0' 
> > 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to puppet...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/4d58c1ea-0652-474f-bc50-c0c150c0eb00o%40googlegroups.com.
>  
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/68801878-cf98-41e2-9d8a-70bd79f2e884o%40googlegroups.com.


Re: [Puppet Users] Puppetdb and postgresql module: How to manage Postgresql but NOT manage Postgresql REPO using Hiera?

2020-06-13 Thread Martin Alfke


postgresql::globals::manage_package_repo: false
postgresql::globals::version: '9.6',

> On 12. Jun 2020, at 17:40, Devminded  wrote:
> 
> Hi.
> 
> I am trying to disable the managing of the Postgresql repo using Hiera when 
> using the puppetlabs/postgresql module. I have tried every Hiera combination 
> I can think of (from reading the docs/code) but nothing works.
>   • puppetdb::database::postgresql::manage_package_repo: false
>   • puppetdb::globals::manage_package_repo: false
>   • postgresql::globals::manage_package_repo: false
> It still adds the /etc/apt/sources.list.d/apt.postgresql.org.list which won't 
> work since we are using our own Aptly mirror and servers cannot directly 
> communicate with the internet, and so the apt update fails and the entire 
> puppet agent run fails with it.
> 
> How do I disable the management of 
> /etc/apt/sources.list.d/apt.postgresql.org.list using Hiera?
> 
> System:
>   • OS: Ubuntu 16.04 and 20.04
>   • puppetserver version: 6.12.0
>   • puppet-version: 6.16.0
>   • mod 'puppetlabs/postgresql', '6.5.0'
>   • mod 'puppetlabs/puppetdb', '7.4.0'
>   • mod 'puppetlabs/stdlib', '6.3.0'
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/4d58c1ea-0652-474f-bc50-c0c150c0eb00o%40googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/7E4067DF-CC0E-4D28-B016-D35A55D787E2%40gmail.com.


[Puppet Users] Puppetdb and postgresql module: How to manage Postgresql but NOT manage Postgresql REPO using Hiera?

2020-06-12 Thread Devminded
Hi.

I am trying to *disable* the managing of the *Postgresql repo* using *Hiera* 
when using the puppetlabs/postgresql module. I have tried every Hiera 
combination I can think of (from reading the docs/code) but nothing works.

   - puppetdb::database::postgresql::manage_package_repo: false
   - puppetdb::globals::manage_package_repo: false
   - postgresql::globals::manage_package_repo: false

It still adds the */etc/apt/sources.list.d/apt.postgresql.org.list* which 
won't work since we are using our own Aptly mirror and servers cannot 
directly communicate with the internet, and so the *apt update* fails and 
the entire puppet agent run fails with it.

*How do I disable the management 
of /etc/apt/sources.list.d/apt.postgresql.org.list using Hiera?*

System:

   - OS: Ubuntu 16.04 and 20.04
   - puppetserver version: 6.12.0
   - puppet-version: 6.16.0
   - 
   - mod 'puppetlabs/postgresql', '6.5.0'
   - mod 'puppetlabs/puppetdb', '7.4.0'
   - mod 'puppetlabs/stdlib', '6.3.0'



-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4d58c1ea-0652-474f-bc50-c0c150c0eb00o%40googlegroups.com.


[Puppet Users] puppetdb "

2020-05-04 Thread Steve Huston
I upgraded via the Puppet repos from puppetdb-6.9.1-1.el7.noarch
(Installed 3/12) to puppetdb-6.10.0-1.el7.noarch today, and restarting
puppetdb fails with this error:

Your PuppetDB database contains a schema migration numbered 1, but
this version of PuppetDB does not recognize that version.

Sure enough (trimmed):

puppetdb=> SELECT * FROM schema_migrations;
 version |  time
-+-
   1 | 2015-02-27 14:48:32.445
   2 | 2015-02-27 14:48:32.452
...
  72 | 2020-02-14 15:16:19.01
  73 | 2020-02-14 15:16:20.313
(73 rows)

Looking in migrate.clj, though I'm not familiar with the language, it
seems that between the commits for 6.9.1 and 6.10.0 some things were
changed including the addition of a migration number '00' for testing
for the presence of the table.  But the rest of the numbers only start
at 28.  It almost seems as if adding the 00 but not 01..27 has caused
the test for unknown migrations to trigger, but again I'm not familiar
with the language so just trying to see what's going on.

-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CANnpg5SZOej-94FrJiJZx4BGoS1%3DUabKcr6qpFjPLFZvkF-aoA%40mail.gmail.com.


[Puppet Users] PuppetDB : unable to upgrade 6.5 to 6.9 => SSL errors

2020-04-27 Thread Yvan Broccard
Hi,

I'm struggling with a simple update of PuppetDB since a couple of days, 
without finding the problem.
I have 4 PuppetServers running Puppetserver 6.9 
(puppetserver-6.9.0-1.el7.noarch). One has the CA role, the 3 others are 
simple masters. I have one dedicated PuppetDB server 
running puppetdb-6.5.0-1.

Everything is working like a charm since a couple of years. It was updated 
from Puppet 3, 4 and 6 without a glitch. Everything is running on CentOS 7.

Now, when I want to update PuppetDb from 6.5 to 6.9, nothing works anymore.

All nodes are complaining with these messages :

Warning: Unable to fetch my node definition, but the agent run will 
continue:
Warning: Error 500 on SERVER: Server Error: Could not retrieve facts for 
vmlabybr06.staging.rsvgnw.local: Failed to find facts from PuppetDB at 
vmprdpuppet41.rsvgnw.local:8140: Failed to execute 
'/pdb/query/v4/nodes/vmlabybr06.staging.rsvgnw.local/facts' on at least 1 
of the following 'server_urls': https://vmctldeploy20.rsvgnw.local:8081
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: Failed to execute 
'/pdb/cmd/v1?checksum=5da252cdae0fc1737726e9ace846d74856395703=5=vmlabybr06.staging.rsvgnw.local=replace_facts=2020-04-09T13:15:44.382Z'
 
on at least 1 of the following 'server_urls': 
https://vmctldeploy20.rsvgnw.local:8081
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run


In the server log I get this :

2020-04-09T15:22:45.169+02:00 WARN  [qtp1002336767-143] 
[c.p.h.c.i.PersistentSyncHttpClient] Error executing http request
javax.net.ssl.SSLException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1647)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1615)
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1781)
at 
sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1070)
at 
sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:896)
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:766)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doUnwrap(SSLIOSession.java:271)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:316)
at 
org.apache.http.nio.reactor.ssl.SSLIOSession.isAppInputReady(SSLIOSession.java:503)
at 
org.apache.http.impl.nio.reactor.AbstractIODispatch.inputReady(AbstractIODispatch.java:120)
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:162)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:337)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:315)
at 
org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:276)
at 
org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at 
org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:588)
at java.lang.Thread.run(Thread.java:748)
2020-04-09T15:22:45.171+02:00 WARN  [qtp1002336767-143] [puppetserver] 
Puppet Error connecting to vmctldeploy20.rsvgnw.local on 8081 at route 
/pdb/cmd/v1?checksum=0f8f2f1e474b2f551f6dc656bff34f1e43e56f6b=8=vmlabvmt01.rsvgnw.local=store_report=2020-04-09T13:22:45.130Z,
 
error message received was 'Error executing http request'. Failing over to 
the next PuppetDB server_url in the 'server_urls' list
2020-04-09T15:22:45.172+02:00 ERROR [qtp1002336767-143] [puppetserver] 
Puppet Failed to execute 
'/pdb/cmd/v1?checksum=0f8f2f1e474b2f551f6dc656bff34f1e43e56f6b=8=vmlabvmt01.rsvgnw.local=store_report=2020-04-09T13:22:45.130Z'
 
on at least 1 of the following 'server_urls': 
https://vmctldeploy20.rsvgnw.local:8081


I have checked a few things :
- Updated puppetdb-termini on the puppet-master from 6.5 to 6.9 (no change)
- added "verify_client_certificate = false" 
to /etc/puppetlabs/puppet/puppetdb.conf on the masters (no change)
- added full certs list to PuppetDB 
server /etc/puppetlabs/puppetdb/ssl/public.pem

I've read there has been a change liked to SSL in the PuppetDB 6.6 
CHANGELOG.

Here is what happens when I try to connect with openssl for 
troubleshooting, to PuppetDB 6.5

openssl s_client -host puppetdb -port 8081 -CAfile 
/etc/puppetlabs/puppet/ssl/certs/ca.pem
CONNECTED(0003)
Can't use SSL_get_servername
depth=1 CN = Puppet CA: vmctldeploy10.rsvgnw.local
verify return:1
depth=0 CN = vmctldeploy20.rsvgnw.local
verify return:1
140503727654720:error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad 
certificate:ssl/record/rec_layer_s3.c:1544:SSL alert number 42

Re: [Puppet Users] PuppetDB latest version has disabled APIv1 metrics

2020-03-15 Thread comport3
Actually attempting to add the mentioned config to file 
'/etc/puppetlabs/puppetserver/conf.d/metrics.conf' results in the 
puppetserver service being unable to start, and this is logged -
clojure.lang.ExceptionInfo: Value does not match schema: 
{:metrics-webservice {:mbeans disallowed-key}}

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2aa7db0c-7cba-44fe-a423-70f21efab2e4%40googlegroups.com.


Re: [Puppet Users] PuppetDB latest version has disabled APIv1 metrics

2020-03-15 Thread comport3
Thanks for this info, I think it points in the right direction.

Are you able to provide any example config or a link to how to action this?

It's not immediately obvious.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fbb6d444-77e2-4f05-bd23-1028015ccdb7%40googlegroups.com.


Re: [Puppet Users] PuppetDB latest version has disabled APIv1 metrics

2020-03-13 Thread Justin Stoller
I believe a config value was added at:
metrics.metrics-webservice.mbeans.enabled
to match the jolokia one that controls v2.
However the default for the mbeans / v1 endpoint is now `false`.

Note that this is now the case for Puppet Server as well and can be
re-enabled with the same config value in its respective conf.d.

hth,
Justin

On Thu, Mar 12, 2020 at 7:23 PM comport3  wrote:

> The latest version of PuppetDB v6.9.1 has removed localhost access to the
> v1 API metrics.
> Ref https://puppet.com/security/cve/CVE-2020-7943/
>
> https://puppet.com/docs/puppet/latest/release_notes_puppet.html#puppet-resolved-issues-x.12.0
>
> Given it's only "disabled by default", this suggests there is (or, should
> be) a way to re-enable it, so we can continue using this excellent Icinga2
> plugin -
> https://github.com/xorpaul/check_puppetdb/
>
> Does anyone know how to re-enable the presently disabled functionality?
>
> This page should have info in my opinion, but doesn't
> https://puppet.com/docs/puppetdb/latest/api/metrics/v1/mbeans.html
>
> Issue tracked here: https://github.com/xorpaul/check_puppetdb/issues/14
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/bd6f9954-9e51-46d4-90f8-0d5fa407402b%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CA%2B%3DBEqWQ_uzLHg48jBnXAgLV%2BjBXqSULYhkRbovN%3D5RDHT1XdQ%40mail.gmail.com.


[Puppet Users] PuppetDB latest version has disabled APIv1 metrics

2020-03-12 Thread comport3
The latest version of PuppetDB v6.9.1 has removed localhost access to the 
v1 API metrics.
Ref https://puppet.com/security/cve/CVE-2020-7943/
https://puppet.com/docs/puppet/latest/release_notes_puppet.html#puppet-resolved-issues-x.12.0

Given it's only "disabled by default", this suggests there is (or, should 
be) a way to re-enable it, so we can continue using this excellent Icinga2 
plugin -
https://github.com/xorpaul/check_puppetdb/

Does anyone know how to re-enable the presently disabled functionality?

This page should have info in my opinion, but doesn't 
https://puppet.com/docs/puppetdb/latest/api/metrics/v1/mbeans.html

Issue tracked here: https://github.com/xorpaul/check_puppetdb/issues/14

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/bd6f9954-9e51-46d4-90f8-0d5fa407402b%40googlegroups.com.


Re: [Puppet Users] PuppetDB Using Puppetlabs Postgresql Module on Linux

2019-12-17 Thread John Warburton
You need to set it in globals. This is what we do:

class { 'postgresql::globals':
version  => $postgresql_version,
datadir  => "${postgres_top}/postgresql/data",
}

John

On Wed, 18 Dec 2019 at 01:49, Peter Krawetzky  wrote:

> I was looking through the documentation and couldn't find my answer.  I
> want to use both the PuppetDB and Postgresql supported modules to install
> and manage both.  I don't want to use the default database directory
> "/var/lib/postgresql/..." but want to specify my own.  What do I use to
> point the database directory to another physical location?  If a different
> location is specified, does the Postgresql module correctly configure
> systemctl stop/start/restart process?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/e01f26bb-b7cf-4d22-ab95-deb8336189b6%40googlegroups.com
> 
> .
>


-- 
John Warburton
Ph: 0417 299 600
Email: jwarbur...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAAJLFxUYNkEGrn0SG5pZXTmkun-O2taP-MRXzq2_HLj6nn%3DfHQ%40mail.gmail.com.


[Puppet Users] PuppetDB Using Puppetlabs Postgresql Module on Linux

2019-12-17 Thread Peter Krawetzky
I was looking through the documentation and couldn't find my answer.  I 
want to use both the PuppetDB and Postgresql supported modules to install 
and manage both.  I don't want to use the default database directory 
"/var/lib/postgresql/..." but want to specify my own.  What do I use to 
point the database directory to another physical location?  If a different 
location is specified, does the Postgresql module correctly configure 
systemctl stop/start/restart process?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e01f26bb-b7cf-4d22-ab95-deb8336189b6%40googlegroups.com.


Re: [Puppet Users] puppetdb query return values

2019-12-13 Thread Austin Blatt
Hi Matt,

You should be able to do that now that we've finished PDB-2634
, which is available in
PuppetDB 6.7.0+.

The { } are still required, so a query could look like

resources[certname, parameters.address] {
  type = "Postgresql::Server::Pg_hba_rule"
  and parameters.address ~ ".*"
}


On Fri, Dec 13, 2019 at 9:54 AM Matt Zagrabelny  wrote:

> Greetings,
>
> I've looked through the puppetdb docs, in particular the PQL docs, to find
> out if I can extract a single parameter in the return value(s).
>
> I have as a PQL:
>
> resources[parameters] { type = "Postgresql::Server::Pg_hba_rule" and
> parameters.address ~ "."}
>
> I'd like to get the "address" parameter. So some pseudocode like:
>
> resources[parameters.address]
>
> I know I can post process the results, but is there a way to get a single
> parameter in PQL?
>
> Thanks,
>
> -m
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAOLfK3UZuh5jvdFjq5giQbifcM5RU6--oL-KDoLo0SuPMCu2KQ%40mail.gmail.com
> 
> .
>


-- 
*Austin Blatt*
Software Engineer
austin.bl...@puppet.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CADVW12PXbtWAgqcjoq3c8op%2BB5iNg-7616u2ZkVtkFbRgh%3DL3A%40mail.gmail.com.


[Puppet Users] puppetdb query return values

2019-12-13 Thread Matt Zagrabelny
Greetings,

I've looked through the puppetdb docs, in particular the PQL docs, to find
out if I can extract a single parameter in the return value(s).

I have as a PQL:

resources[parameters] { type = "Postgresql::Server::Pg_hba_rule" and
parameters.address ~ "."}

I'd like to get the "address" parameter. So some pseudocode like:

resources[parameters.address]

I know I can post process the results, but is there a way to get a single
parameter in PQL?

Thanks,

-m

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAOLfK3UZuh5jvdFjq5giQbifcM5RU6--oL-KDoLo0SuPMCu2KQ%40mail.gmail.com.


Re: [Puppet Users] puppetdb 6x not deactivating from catalogs table

2019-10-09 Thread Andy Hall
Thanks Zachary that doc is a great help. I'll lower the node-purge-ttl and 
see how it performs.

On Friday, 4 October 2019 22:14:04 UTC+1, Zachary Kent wrote:
>
> Hi Andy,
>
> Are you seeing the deactivated nodes' catalogs turn up in query results 
> from PDB or only when you query the postgres table directly?
>
> I'm wondering if you might be hitting some strangeness around the 
> node-purge-ttl 
>  
> setting. This setting specifies the amount of time that the PDB garbage 
> collection process will wait before permanently deleting a node even if it 
> has been deactivated or expired. This setting is needed on the enterprise 
> side of things but could be preventing the nodes that you have deactivated 
> from being deleted right away. 
>
> I tried setting this value to node-purge-ttl=1s locally and was able to 
> confirm that deactivating a node and then sending a purge_nodes command 
> 
>  
> to the admin endpoint triggered gc and deleted the node.
>
> Note that if you do try this approach you may want to consider using a 
> batch_limit for the purge_nodes admin command. Otherwise the PDB will try 
> to delete everything at once which may take a while. See this blog post 
> 
>  
> that discusses some of the related issues. 
>
> Changing this setting will also speed up the purging of data from nodes 
> that have fallen inactive for longer than node-ttl 
>  which is 
> another thing to consider if you care about querying for nodes that have 
> stopped checking in longer than node-ttl. 
>
> Hope this helps!
>
>
> On Thu, Oct 3, 2019 at 10:25 AM Andy Hall  > wrote:
>
>> hey there we have just migrated hundreds of hosts from 3.x to 6.x and 
>> although lots of work we are almost home and dry but have an issue with 
>> puppetdb which I hope can be solved. we are running puppetdb-6.3.4 but when 
>> removing an old node as follows:
>>
>> puppet node deactivate 
>>
>> the information is _not_ getting removed from puppetdb and we have to run 
>> the following sql manually:
>>
>> delete from catalogs where certname in (select certname from certnames 
>> where deactivated is not null);
>>
>> this is far from ideal and we really need this functionality to work 
>> again as we have numerous exported resources such as nagios which have to 
>> be removed when decommissioning a host.
>>
>> please advise if this is a known issue or if we are doing something wrong.
>>
>> thanks very much and keep up the good work !!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/9f3a3c96-29ec-401d-b3d4-cf6b8270535f%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6c54e96c-e09f-4e24-9bd1-b09d7c9d8919%40googlegroups.com.


Re: [Puppet Users] puppetdb 6x not deactivating from catalogs table

2019-10-04 Thread Zachary Kent
Hi Andy,

Are you seeing the deactivated nodes' catalogs turn up in query results
from PDB or only when you query the postgres table directly?

I'm wondering if you might be hitting some strangeness around the
node-purge-ttl

setting. This setting specifies the amount of time that the PDB garbage
collection process will wait before permanently deleting a node even if it
has been deactivated or expired. This setting is needed on the enterprise
side of things but could be preventing the nodes that you have deactivated
from being deleted right away.

I tried setting this value to node-purge-ttl=1s locally and was able to
confirm that deactivating a node and then sending a purge_nodes command

to the admin endpoint triggered gc and deleted the node.

Note that if you do try this approach you may want to consider using a
batch_limit for the purge_nodes admin command. Otherwise the PDB will try
to delete everything at once which may take a while. See this blog post

that discusses some of the related issues.

Changing this setting will also speed up the purging of data from nodes
that have fallen inactive for longer than node-ttl
 which is
another thing to consider if you care about querying for nodes that have
stopped checking in longer than node-ttl.

Hope this helps!


On Thu, Oct 3, 2019 at 10:25 AM Andy Hall  wrote:

> hey there we have just migrated hundreds of hosts from 3.x to 6.x and
> although lots of work we are almost home and dry but have an issue with
> puppetdb which I hope can be solved. we are running puppetdb-6.3.4 but when
> removing an old node as follows:
>
> puppet node deactivate 
>
> the information is _not_ getting removed from puppetdb and we have to run
> the following sql manually:
>
> delete from catalogs where certname in (select certname from certnames
> where deactivated is not null);
>
> this is far from ideal and we really need this functionality to work again
> as we have numerous exported resources such as nagios which have to be
> removed when decommissioning a host.
>
> please advise if this is a known issue or if we are doing something wrong.
>
> thanks very much and keep up the good work !!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/9f3a3c96-29ec-401d-b3d4-cf6b8270535f%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CADNLmiva8yp3ZMfgR8%2BSammBkApKbPSZjG%3Dg%2BNeh3sdnyP48LA%40mail.gmail.com.


[Puppet Users] puppetdb 6x not deactivating from catalogs table

2019-10-03 Thread Andy Hall
hey there we have just migrated hundreds of hosts from 3.x to 6.x and 
although lots of work we are almost home and dry but have an issue with 
puppetdb which I hope can be solved. we are running puppetdb-6.3.4 but when 
removing an old node as follows:

puppet node deactivate 

the information is _not_ getting removed from puppetdb and we have to run 
the following sql manually:

delete from catalogs where certname in (select certname from certnames 
where deactivated is not null);

this is far from ideal and we really need this functionality to work again 
as we have numerous exported resources such as nagios which have to be 
removed when decommissioning a host.

please advise if this is a known issue or if we are doing something wrong.

thanks very much and keep up the good work !!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9f3a3c96-29ec-401d-b3d4-cf6b8270535f%40googlegroups.com.


Re: [Puppet Users] PuppetDB 5.2: How to find list of certnames from puppetdb where serverrole is "umg" using API

2019-07-17 Thread Biraj Sahu
Hello Austin,
Thanks for your reply.

The issue is I am trying to return certnames based on server_role which I
dont think is a fact, correct me if I am wrong. And since puppet 5.2, we
have nested key, values and not sure how do I reach that leaf. Please check
the json snippet, if you haven't checked yet.

Thanks
Biraj

On Wed, Jul 17, 2019 at 3:55 AM Austin Blatt 
wrote:

> Apologies in advance if I didn't interpret your query properly, but I
> believe you are looking to return the certnames of servers that have a
> specific fact with a specific value, the best endpoint for that would
> probably be inventory
>  (or
> maybe fact-contents
> ).
> A curl command for the inventory endpoint could look like this.
>
> curl -X POST http://:8080/pdb/query/v4 \
>   -H 'Content-Type:application/json' \
>   -d '{"query": "inventory[certname] { facts.path.to.fact = \"your-value\"
> }" }'
>
> The fact-content query would look similar, but you'd need to match path
> and value there and it doesn't support dot notation like the inventory
> endpoint.
>
> On Tue, Jul 16, 2019 at 10:16 AM Biraj Sahu  wrote:
>
>>
>> PuppetDB version- 5.2
>>
>> I want to retrieve list of servers with a specific role- tata_umg
>>
>>
>>
>> The json is in below format:
>>
>> [
>>
>>  {
>>
>>  "certname":"",
>>
>>  "environment":"",
>>
>>  "name":"_clientname",
>>
>>  "value":{
>>
>> "clientabc":{
>>
>>"_productname":{
>>
>>   "tata":{
>>
>>  "_instanceid":"0",
>>
>>  "_serverrole":[
>>
>> "tata_umg"
>>
>>  ]
>>
>>   }
>>
>>}
>>
>> }
>>
>>  }
>>
>>   }]
>>
>> Can use below 2 get requests to reterive:
>>
>> curl -X GET '
>> http://puppetdb.aws.internal:8080/pdb/query/v4/facts/_clientname'
>>
>> curl -X GET 'http://puppetdb.aws.internal:8080/pdb/query/v4/facts'
>> --data-urlencode 'query=["=", "name", "_clientname"]'
>>
>>
>>
>> But this gives me a json with all server's - '_clientname' and not
>> specific to a certain role.
>>
>>
>>
>> Can anyone please help me update the query to make it work as per my need.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/8d2e4bc6-762e-4349-ac28-e20d587d36df%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> *Austin Blatt*
> Associate Software Engineer
> austin.bl...@puppet.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CADVW12Mn9LhuvtmqLpxbG5BWPbvsGHJaRK6Pybywg5eHEA__7g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
BIRAJ
Pune
Ph no-08861077222

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAHJs-WDtJgYOJyGnxR2k1p2x39rezU-ghJD0Oms-L8snvWh%2B3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB 5.2: How to find list of certnames from puppetdb where serverrole is "umg" using API

2019-07-16 Thread Austin Blatt
Apologies in advance if I didn't interpret your query properly, but I
believe you are looking to return the certnames of servers that have a
specific fact with a specific value, the best endpoint for that would
probably be inventory
 (or
maybe fact-contents
). A
curl command for the inventory endpoint could look like this.

curl -X POST http://:8080/pdb/query/v4 \
  -H 'Content-Type:application/json' \
  -d '{"query": "inventory[certname] { facts.path.to.fact = \"your-value\"
}" }'

The fact-content query would look similar, but you'd need to match path and
value there and it doesn't support dot notation like the inventory endpoint.

On Tue, Jul 16, 2019 at 10:16 AM Biraj Sahu  wrote:

>
> PuppetDB version- 5.2
>
> I want to retrieve list of servers with a specific role- tata_umg
>
>
>
> The json is in below format:
>
> [
>
>  {
>
>  "certname":"",
>
>  "environment":"",
>
>  "name":"_clientname",
>
>  "value":{
>
> "clientabc":{
>
>"_productname":{
>
>   "tata":{
>
>  "_instanceid":"0",
>
>  "_serverrole":[
>
> "tata_umg"
>
>  ]
>
>   }
>
>}
>
> }
>
>  }
>
>   }]
>
> Can use below 2 get requests to reterive:
>
> curl -X GET '
> http://puppetdb.aws.internal:8080/pdb/query/v4/facts/_clientname'
>
> curl -X GET 'http://puppetdb.aws.internal:8080/pdb/query/v4/facts'
> --data-urlencode 'query=["=", "name", "_clientname"]'
>
>
>
> But this gives me a json with all server's - '_clientname' and not
> specific to a certain role.
>
>
>
> Can anyone please help me update the query to make it work as per my need.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/8d2e4bc6-762e-4349-ac28-e20d587d36df%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
*Austin Blatt*
Associate Software Engineer
austin.bl...@puppet.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CADVW12Mn9LhuvtmqLpxbG5BWPbvsGHJaRK6Pybywg5eHEA__7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB 5.2: How to find list of certnames from puppetdb where serverrole is "umg" using API

2019-07-16 Thread Biraj Sahu

PuppetDB version- 5.2

I want to retrieve list of servers with a specific role- tata_umg



The json is in below format:

[

 {

 "certname":"",

 "environment":"",

 "name":"_clientname",

 "value":{

"clientabc":{

   "_productname":{

  "tata":{

 "_instanceid":"0",

 "_serverrole":[

"tata_umg"

 ]

  }

   }

}

 }

  }]

Can use below 2 get requests to reterive:

curl -X GET 
'http://puppetdb.aws.internal:8080/pdb/query/v4/facts/_clientname'

curl -X GET 'http://puppetdb.aws.internal:8080/pdb/query/v4/facts' 
--data-urlencode 'query=["=", "name", "_clientname"]'



But this gives me a json with all server's - '_clientname' and not 
specific to a certain role.



Can anyone please help me update the query to make it work as per my need.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8d2e4bc6-762e-4349-ac28-e20d587d36df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Puppetdb installed with puppetlabs/puppetdb migration 65 failing

2019-06-26 Thread Farko
Hi all!

Added the puppetdb module, runs through and gets stuck on boot with the 
following error:

2019-06-26 14:20:21,638 INFO  [p.p.s.migrate] Applying database migration 
version 65

2019-06-26 14:20:21,673 ERROR [p.p.s.migrate] Caught SQLException during 
migration

...

2019-06-26 14:20:21,675 ERROR [p.p.s.migrate] Unravelled exception
org.postgresql.util.PSQLException: ERROR: relation 
"resource_events_status_for_corrective_change_idx" already exists
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2284)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2003)
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:360)
at 
org.postgresql.jdbc.PgStatement.executeBatch(PgStatement.java:1019)

Tried dropping the puppetdb database, and restarting puppetdb, same error 
occurs.

puppetdb version: 5.2.8

Thank you!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/05307cf2-ea4e-4081-9217-44bbcf7528cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB failing to start up with bizarre complaint

2019-05-22 Thread Peter Berghold
Using the puppetlabs/puppetdb module to manage PuppetDB I'm seeing way to
much red text and PuppetDB is not "refreshing" meaning restarting. It is
failing with an error message
 java.lang.IllegalArgumentException: Specified bootstrap config file does
not exist: '/etc/puppetlabs/puppetdb/bootstrap.cfg'

and yet the file is really there and contains:

# 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

so... what is really going on here?
-- 

Peter L. Berghold   salty.cowd...@gmail.com

http://devops.berghold.net

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAArvnv3_t0401gqSe8WQPQgRM_LU8SjV2DEjxM3GnF4PMnFAoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB exported resources with hiera-eyaml

2019-01-14 Thread Jocelyn Thode
Thanks for the detailed answer Erik. I was not able to @ you in the github 
issue as I did not know your username however you seem to have found it alone.

Best
Jocelyn 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8a88c810-5269-4344-a85c-c13cc5489496%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB exported resources with hiera-eyaml

2019-01-10 Thread Henrik Lindberg

On 2019-01-10 10:56, Jocelyn Thode wrote:

Hey,

I'm trying to use exported resources where one of the parameter of the 
resource is a variable from hiera. This variable is retrieved using 
automatic lookup and is encrypted in hiera using hiera-eyaml.


However when the ressource is exported insted of the clear password 
being exported, I get the base64 encoded version of the clear password 
as argument. This does not happen if I don't use a hiera-eyaml encrypted 
password.


Any idea why ?


I think that is because hiera-eyaml ends up returning ASCII-8bit encoded 
clear text strings which is then interpreted as potentially being binary 
and non UTF-8 compliant and therefore sent as a Binary (which gets 
encoded as Base64 text).


This problem should be fixed in hiera-eyaml as it should return Strings 
with UTF8 encoding. This may depend on the encoding of the original yaml 
file that hiera-eyaml read.


It is a bit difficult to check if what I suspect is true. I would write 
a function (or call a simple function such as "with()"), do a lookup and 
pass the value to the function, I would then use a debugger, set a 
breakpoint in the function, and check the encoding
of the string given to the function. To test what hiera-eyaml does 
requires debugging hiera-eyaml.


Some background:

Before puppet 6 the default format was JSON with fallback to PSON if 
strings were ascii-8bit. Since puppet 6, we use "rich-data encoding" by 
default and handle ascii-8bit as being Binary - and by not using PSON.


We did work on issues related to export to PDB from puppet and it may be 
that a newer puppet versions does a better job with ascii-8bit that can 
be converted to UTF-8 without problems.


In summary, I think this should be logged as a ticket for hiera-eyaml.
Feel free to ping me on that ticket if the maintainers of hiera-eyaml 
needs a hand with figuring things out.


Best,

- henrik



Puppet version: 6.0.4

Puppetdb version: 6.1.0

Puppetserver version: 6.0.2



--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/q18e65%24dpn%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB exported resources with hiera-eyaml

2019-01-10 Thread Jocelyn Thode
Hey,

I'm trying to use exported resources where one of the parameter of the 
resource is a variable from hiera. This variable is retrieved using 
automatic lookup and is encrypted in hiera using hiera-eyaml.

However when the ressource is exported insted of the clear password being 
exported, I get the base64 encoded version of the clear password as 
argument. This does not happen if I don't use a hiera-eyaml encrypted 
password.

Any idea why ?

Puppet version: 6.0.4

Puppetdb version: 6.1.0

Puppetserver version: 6.0.2

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/bb8f4aa1-d52f-417c-a296-15560491d191%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb - WITH inactive_nodes AS (SELECT certname

2018-08-20 Thread Steve Traylen


Hi,

We recently upgraded to puppetdb 4.4.

There is query that takes a while to run, 3 or 4 minutes though we are 
unsure of why it is even running.

The query below looks related to some kind of clean up or garbage 
collection however this particular puppetdb node has two relevant 
properties:

* gc-interval is set to 0 and indeed there are no gc events in the logs.
* This particular node only receives /pdb/query requests and no /pdb/cmd 
requests. We have always and still do dedicate nodes to command and query 
traffic by redirection at haproxy level.

What is the action that triggers the query below. 

WITH inactive_nodes AS (SELECT certname FROM certnames WHERE (deactivated 
IS NOT NULL OR expired IS NOT NULL)) SELECT fs.certname AS certnam e, 
fp.name AS name, f.value AS value FROM factsets fs INNER JOIN facts f ON 
fs.id = f.factset_id INNER JOIN fact_paths fp ON f.fact_path_id = fp.id 
INNER JOIN value_types vt ON vt.id = f .value_type_id LEFT JOIN 
environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND 
(fs.certname) in ( (SELECT fs.certname AS certname FROM factsets fs 
INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_paths fp ON 
f.fact_path_id = fp.id INNER JOIN value_types vt ON f.value_type_id = vt.id 
LEFT JOIN environments env ON fs.environment_id = env.id WHERE (vt.id <> 5 
AND ((fp.path = $1) AND (f.value_string = $2 ) ) AND ((fs.certname) in 
( (SELECT fs.certname AS certname FROM factsets fs INNER JOIN facts f ON 
fs.id = f.factset_ id INNER JOIN fact_paths fp ON f.fact_path_id = fp.id 
INNER JOIN value_types vt ON f.value_type_id = vt.id LEFT JOIN environments 
env ON fs.environment_id = env.id WHERE (vt.id <> 5 AND ((fp.path = $3) AND 
(f.value_string = $4 ) )) AND ((fp.name = $5) OR (fp.name = $6))) AND 
NOT ((fs.certname) in ( (SELECT inactive_nodes.certname AS certname FROM 
inactive_nodes) ) )))

Steve Traylen.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9dc72799-c4cb-455b-a210-3878a3884d94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB 4.4 API - Getting ALL events (changes and no-changes)

2018-06-27 Thread FE Williams
I need to programmatically present all events for a given node from the 
latest report for audits of server Security Controls we're managing with 
Puppet - pretty much the way events look in the PE Console when looking at 
a report - whether the event was a success or not, and whether or not a 
resource property was changed or not.  Querying Events (on puppetca: curl 
-G http://127.0.0.1:8080/pdb/query/v4/events --data-urlencode 'query=["=", 
"report", "fa6dcbc36b69174178e1234561d4c6e461017327"]' )   seems to only 
send results of resource properties that were changed by puppet (and 
returns nothing at all if there were no changes.  Does anybody know how to 
get the events where there was no change?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/aa5a8ab6-ec4c-4db4-b67f-7f918a2b2763%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB: manually import reports

2018-04-26 Thread jcbollinger


On Wednesday, April 25, 2018 at 6:22:39 AM UTC-5, Thomas Müller wrote:
>
>
>  
>>
>>>
>>> Another usecase could be to have a async puppetdb connection from the 
>>> second datacenter. If the connection between the datacenters is not  stable 
>>> enough to use a single puppetdb I would need to add a puppetdb per DC.Then 
>>> I also would want to sync data to the central puppetdb instance.
>>>
>>>
>> Is that an *actual* use case or a hypothetical one?
>>
>> I'm just thinking what my options are if it the datacenter link is not 
> stable enough. I'm not investing time to create a solution.
>
> I've thought a bit longer about the "importing reports". it's not just 
> importing reports, it's also importing facts and importing catalogs to the 
> central db. Overall I think this really would require much time to 
> implement the tooling. Maybe then it will be easier to query 2 puppetdb's 
> instead of syncing everything to one. 
>
> But maybe all works out fine and no hacking will be necessary. :)
>
>
There are Postgres-level tools for database federation and 
synchronization.  As I already suggested, something along those lines is 
probably worth your consideration as a mechanism for the actual data 
movement.  The other question to consider is how to structure the data so 
that it even makes sense to combine them at all, and again, at a bare 
minimum, your various participating masters should rely on a common CA.  To 
a good approximation, the CA identity is the site identity, and it does not 
make much sense to combine data from different sites in the same database.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/feed1ef2-7f3e-40a0-8cb4-ef7532ee4813%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB: manually import reports

2018-04-25 Thread Thomas Müller


>  
>
>>
>> Another usecase could be to have a async puppetdb connection from the 
>> second datacenter. If the connection between the datacenters is not  stable 
>> enough to use a single puppetdb I would need to add a puppetdb per DC.Then 
>> I also would want to sync data to the central puppetdb instance.
>>
>>
> Is that an *actual* use case or a hypothetical one?
>
> I'm just thinking what my options are if it the datacenter link is not 
stable enough. I'm not investing time to create a solution.

I've thought a bit longer about the "importing reports". it's not just 
importing reports, it's also importing facts and importing catalogs to the 
central db. Overall I think this really would require much time to 
implement the tooling. Maybe then it will be easier to query 2 puppetdb's 
instead of syncing everything to one. 

But maybe all works out fine and no hacking will be necessary. :)

- Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/6baf2a50-fb0c-4b65-9002-2ba30d5eb05c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB: manually import reports

2018-04-20 Thread Wyatt Alt


On 4/19/18 4:46 AM, Thomas Müller wrote:

HI

I've got some prod puppetserver/puppetdb and some dev 
puppetserver/puppetdb. But to have the complete overview over all 
nodes with the prod puppetdb I'd like to import the reports from the 
dev puppetserver (stored by reports=store config) into the prod puppetdb.


is there some hidden tool to do so? I wasn't able to find anything in 
that direction.


Reading 
https://github.com/puppetlabs/puppetdb/blob/master/puppet/lib/puppet/reports/puppetdb.rb 
this could maybe adapted to read a yaml file and then send it to puppetdb.


If I'm understanding you right, you could normally use the import/export 
tools for this:


https://puppet.com/docs/puppetdb/5.0/anonymization.html#using-the-export-command

There's a corresponding "admin" API on PuppetDB you can search for. The 
process would be to do an export, extract the resulting tarball and 
remove everything but reports (if desired), then tar it up again and run 
it through the import tool. Unfortunately though, this is broken for me 
on current PDB due to PDB-3796. If you're on an older version it may be 
worth a try -- it worked at some point. If you've got the bug it'll 
cause your dev server to OOM and restart.


Assuming that's broken for you too, I think the most tractable way to do 
what you're asking is basically what you're suggesting -- either parse 
the yaml reports into the report wire format 
(https://puppet.com/docs/puppetdb/5.1/api/wire_format/report_format_v8.html) 
and post to your prod PDB's commands endpoint 
(https://puppet.com/docs/puppetdb/5.1/api/command/v1/commands.html) or 
get the json reports out of your dev PuppetDB, in batches to work around 
the bug, and do the equivalent parsing/posting. The wire formats change 
from time to time so take care to use whatever version of the docs 
aligns with your PDB version.


Wyatt




- Thomas
--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d5a3b811-655f-4497-84de-a5693954d08e%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ae2bf29b-c3e5-c0cf-8bff-a75258cad299%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB: manually import reports

2018-04-20 Thread jcbollinger


On Thursday, April 19, 2018 at 2:30:11 PM UTC-5, Thomas Müller wrote:
>
>
>
> Am Donnerstag, 19. April 2018 19:18:34 UTC+2 schrieb Christopher Wood:
>>
>> To challenge an assumption, what are you gaining from having more than 
>> one puppet infrastructure (puppetservers+puppetdb)? 
>>
>> Could you perhaps handle your dev stuff with another environment or set 
>> of puppetservers under the same CA with the same puppetdb? 
>>
>> Is there any reason for a separate puppet infrastructure to live longer 
>> than it takes to proof an upgrade for production? 
>>
>
> I can't just throw away the dev infra after preparing changes for prod 
> because of non-technical reasons. i'm limiting the usage of the dev system 
> as much as I can, but there will be system connected to this dev infra. but 
> I also want the data in the prod puppetdb to have a single point to make 
> queries/reports (third party departments) or run octocatalog-diff to run 
> against real facts from any system. 
>


That seems to respond only to Am's last question.  You can have varying 
degrees of dev / prod separation while still maintaining a shared CA and 
puppetdb, and that has nothing to do with the lifetime or life cycle of the 
dev machines.  I strongly advise at least the shared CA if you're 
contemplating combining dev and prod data by any mechanism.

There are several good reasons to prefer the minimum separation of Puppet 
infrastructure, especially since for at least some purposes, you want to 
aggregate the dev and prod data.  And doing so would take care of the 
problem up front -- there would be no extra step needed to aggregate dev 
and prod data, because it would not be physically separated in the first 
place.
 

>
> Another usecase could be to have a async puppetdb connection from the 
> second datacenter. If the connection between the datacenters is not  stable 
> enough to use a single puppetdb I would need to add a puppetdb per DC.Then 
> I also would want to sync data to the central puppetdb instance.
>
>
Is that an *actual* use case or a hypothetical one?

If hypothetical, then don't let it influence your decisions about your 
actual use cases: if and when you need to account for that, the details 
will matter, and the technological landscape will have changed, so any 
time, effort, and compromises made to accommodate it now will probably be 
wasted.  If it never materializes as an actual use case, then resources 
spent now to accommodate it will *definitely* be wasted.

If you do need to account for it now, then you should still use at least a 
common CA.  It might make sense to use common aggregated puppetdb database, 
too, maybe supported by database synchronization between the PG instances 
at the PG level.  It's hard to make good recommendations, however, without 
a better handle on the requirements for this scenario.


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/09201110-7ca2-4757-ae3d-56e7b3e08346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB: manually import reports

2018-04-19 Thread Thomas Müller


Am Donnerstag, 19. April 2018 19:18:34 UTC+2 schrieb Christopher Wood:
>
> To challenge an assumption, what are you gaining from having more than one 
> puppet infrastructure (puppetservers+puppetdb)? 
>
> Could you perhaps handle your dev stuff with another environment or set of 
> puppetservers under the same CA with the same puppetdb? 
>
> Is there any reason for a separate puppet infrastructure to live longer 
> than it takes to proof an upgrade for production? 
>

I can't just throw away the dev infra after preparing changes for prod 
because of non-technical reasons. i'm limiting the usage of the dev system 
as much as I can, but there will be system connected to this dev infra. but 
I also want the data in the prod puppetdb to have a single point to make 
queries/reports (third party departments) or run octocatalog-diff to run 
against real facts from any system. 

Another usecase could be to have a async puppetdb connection from the 
second datacenter. If the connection between the datacenters is not  stable 
enough to use a single puppetdb I would need to add a puppetdb per DC.Then 
I also would want to sync data to the central puppetdb instance.

- Thomas

 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/359e0529-421d-4acf-9569-3b2902a5f452%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB: manually import reports

2018-04-19 Thread Christopher Wood
To challenge an assumption, what are you gaining from having more than one 
puppet infrastructure (puppetservers+puppetdb)?

Could you perhaps handle your dev stuff with another environment or set of 
puppetservers under the same CA with the same puppetdb?

Is there any reason for a separate puppet infrastructure to live longer than it 
takes to proof an upgrade for production?

On Thu, Apr 19, 2018 at 04:46:01AM -0700, Thomas Müller wrote:
>HI
> 
>I've got some prod puppetserver/puppetdb and some dev
>puppetserver/puppetdb. But to have the complete overview over all nodes
>with the prod puppetdb I'd like to import the reports from the dev
>puppetserver (stored by reports=store config) into the prod puppetdb.
> 
>is there some hidden tool to do so? I wasn't able to find anything in that
>direction.
> 
>Reading
>
> https://github.com/puppetlabs/puppetdb/blob/master/puppet/lib/puppet/reports/puppetdb.rb
>this could maybe adapted to read a yaml file and then send it to puppetdb.
> 
>- Thomas
> 
>--
>You received this message because you are subscribed to the Google Groups
>"Puppet Users" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/d5a3b811-655f-4497-84de-a5693954d08e%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/d5a3b811-655f-4497-84de-a5693954d08e%40googlegroups.com?utm_medium=email_source=footer
>3. https://groups.google.com/d/optout

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20180419171825.hpvbgkvkxyisl5ki%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB: manually import reports

2018-04-19 Thread Thomas Müller
HI 

I've got some prod puppetserver/puppetdb and some dev 
puppetserver/puppetdb. But to have the complete overview over all nodes 
with the prod puppetdb I'd like to import the reports from the dev 
puppetserver (stored by reports=store config) into the prod puppetdb.

is there some hidden tool to do so? I wasn't able to find anything in that 
direction. 

Reading 
https://github.com/puppetlabs/puppetdb/blob/master/puppet/lib/puppet/reports/puppetdb.rb
 
this could maybe adapted to read a yaml file and then send it to puppetdb.

- Thomas 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d5a3b811-655f-4497-84de-a5693954d08e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB catalog-hash-conflict-debugging substitute

2018-04-06 Thread Christopher Wood
Once upon a time I successfully used catalog-hash-conflict-debugging to find an 
unsorted thing being different in every catalog and that was very helpful. 
Recently catalog duplication (in the PuppetDB dashboard) has dropped about 10% 
and the setting is gone from PuppetDB in 5.2.0.

https://tickets.puppetlabs.com/browse/PDB-1931
https://tickets.puppetlabs.com/browse/PDB-1932

Is there a way of storing and diffing different catalogs to see why duplication 
percentage may have dropped?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20180406191054.nyfhmmw4nujrlwaa%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Upgrade Question from 2.1.1-1 to 2.7.2-1

2017-09-22 Thread Wyatt Alt

Hey Peter,

PuppetDB never released a 2.7 series (highest 2.x went was 2.3.x), so 
it's tough to answer your question specifically. In general, the size of 
your data (for which number of nodes is a proxy) can definitely have a 
large effect on migration times, but it largely depends on the specific 
upgrade. Structured facts landed sometime in 2.x after 2.1 and was a 
relatively heavy migration, but there are many other examples.


Wyatt

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ef1f076e-c43d-a34b-41c4-0993766b5c20%40puppet.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB Upgrade Question from 2.1.1-1 to 2.7.2-1

2017-09-21 Thread Peter Krawetzky
I'm doing a minor upgrade from 2.1.1-1 to 2.7.2-1 and was wondering if the 
size of the database makes a difference in how long the upgrade takes? 
 It's currently managing approximately 3200+ nodes in production.  Testing 
in our lab environment did not run long as we only manage about 500 nodes 
there.  Was wondering if there is a correlation between the number of nodes 
and the upgrade process since it's really not described well in the 
documentation.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/81457007-c2f1-4775-ad21-d55415901d8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Curl Queries

2017-07-11 Thread R.I.Pienaar
Best to use PQL via 'puppet query'

Examples:
https://docs.puppet.com/puppetdb/5.0/api/query/examples-pql.html

On Tue, Jul 11, 2017, at 17:48, Peter Krawetzky wrote:
> Using CURL to query PuppetDB has got to be the most time consuming thing 
> I've ever done.  It took me almost 3 hours one day to create a CURL query 
> that I ended up creating in a SQL statement in 10 minutes once I figured 
> out the database structure.
> 
> Does anyone have:
> 
>1. A documented list of CURL queries and the syntax
>2. A documented list of SQL queries to directly against the Postgresql 
>database
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/8d8e9b09-0c05-4ae8-afcf-48d6a83f8247%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


-- 
R.I.Pienaar / www.devco.net / @ripienaar

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1499788471.3231435.1037451160.0703FCC7%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB Curl Queries

2017-07-11 Thread Peter Krawetzky
Using CURL to query PuppetDB has got to be the most time consuming thing 
I've ever done.  It took me almost 3 hours one day to create a CURL query 
that I ended up creating in a SQL statement in 10 minutes once I figured 
out the database structure.

Does anyone have:

   1. A documented list of CURL queries and the syntax
   2. A documented list of SQL queries to directly against the Postgresql 
   database


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8d8e9b09-0c05-4ae8-afcf-48d6a83f8247%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB low catalog-duplication rate Puppet DB 4.3.0

2017-06-28 Thread Christopher Wood
I had a broadly similar issue in that I had a low catalog duplication rate and 
I had to change some puppet manifests around to fix that.

Back in 2015 I was doing this to get mcollective plugin sources for the file 
resource:

source => regsubst(keys($plugins), '^', 'puppet:///modules/mco/plugins/')

But obviously keys() returns things in any old order and every catalog was 
different. The solution was to sort it:

source => regsubst(sort(keys($plugins)), '^', 'puppet:///modules/mco/plugins/')

In your place I would grab some different catalogs for the same host, 
pretty-format them and diff to see what's different. That will show you what's 
changing between runs. The easy way for this is to do a bunch of agent runs and 
then use curl in between them on the puppetdb host.

curl http//localhost:8080/pdb/query/v4/catalogs/host.domain.com | python -m 
json.tool >/tmp/cat1

On Wed, Jun 28, 2017 at 11:11:17AM -0700, Mike Sharpton wrote:
>Hey all,
>I am hoping there is someone else in the same boat as I am.  We are
>running Puppet 4.2.2, along with PuppetDB 4.3.0.  I am seeing low
>duplication rate which I think is contributing to our queuing problems in
>PuppetDB.  The queue will fluctuate from 0-100 queued, to up to 2000.  We
>have around 4500 nodes, and we are using 8 threads on our PuppetDB server.
> I am seeing that the low duplication rate is caused by hashes not
>matching and a full insert running which is expensive on the DB instead of
>just updating the time stamp.  I don't know why these would not be
>matching, and may need help as far as how to find something like this.  I
>see items in PuppetDB3 for this, but not 4.  I see that using timestamp
>and other items which change each time will cause the catalog to never be
>the same, but I would think we would have 0% duplication if this was the
>case.  I am also seeing that things are improved in 4.4.0 as far as
>performance and a missing index is corrected that may speed things.  I am
>wondering what others have done/seen with this and whether upgrading to
>4.4.0 would do me good.  I am thinking it would as many things appear to
>fixed around the issues I am seeing.  Thanks in advance,
>Mike
> 
>--
>You received this message because you are subscribed to the Google Groups
>"Puppet Users" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to [1]puppet-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>
> [2]https://groups.google.com/d/msgid/puppet-users/bde7abd4-fccb-420b-b3d8-d4c674ca5705%40googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:puppet-users+unsubscr...@googlegroups.com
>2. 
> https://groups.google.com/d/msgid/puppet-users/bde7abd4-fccb-420b-b3d8-d4c674ca5705%40googlegroups.com?utm_medium=email_source=footer
>3. https://groups.google.com/d/optout

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20170628192618.5kwip7wdxr62hajo%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB low catalog-duplication rate Puppet DB 4.3.0

2017-06-28 Thread Mike Sharpton
Hey all,

I am hoping there is someone else in the same boat as I am.  We are running 
Puppet 4.2.2, along with PuppetDB 4.3.0.  I am seeing low duplication rate 
which I think is contributing to our queuing problems in PuppetDB.  The 
queue will fluctuate from 0-100 queued, to up to 2000.  We have around 4500 
nodes, and we are using 8 threads on our PuppetDB server.  I am seeing that 
the low duplication rate is caused by hashes not matching and a full insert 
running which is expensive on the DB instead of just updating the time 
stamp.  I don't know why these would not be matching, and may need help as 
far as how to find something like this.  I see items in PuppetDB3 for this, 
but not 4.  I see that using timestamp and other items which change each 
time will cause the catalog to never be the same, but I would think we 
would have 0% duplication if this was the case.  I am also seeing that 
things are improved in 4.4.0 as far as performance and a missing index is 
corrected that may speed things.  I am wondering what others have done/seen 
with this and whether upgrading to 4.4.0 would do me good.  I am thinking 
it would as many things appear to fixed around the issues I am seeing. 
 Thanks in advance,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/bde7abd4-fccb-420b-b3d8-d4c674ca5705%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql

2017-06-28 Thread Peter Krawetzky
Last Sunday we hit a wall on our 3.0.2 puppetdb server.  The cpu spiked and 
the KahaDB logs started to grow eventually almost filling a filesystem.  I 
stopped the service, removed the mq directory per a troubleshooting guide, 
and restarted.  After several minutes the same symptoms began again and I 
have not been able to come up with a puppetdb or postgresql config to fix 
this.

We tried turning off storeconfig in the puppet.conf file on our puppet 
master servers but that doesn't appear to have resolved the problem.  I 
also can't find a good explanation as to what this parameter really does or 
does not do even in the puppet server documentation.  Anyone have a better 
insight into this?

Also is there a way to just turn off puppetdb?

I've attached a file that is a snapshot of the puppetdb dashboard.

Anyone experience anything like this?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f6a49085-8b32-4fa2-9f6b-e8beb3f8175e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB / hiera and Sensitive() questions

2017-05-05 Thread Denny Fuchs
Hello,


   - Puppet: node: 3.7.2-4 / puppet server: 2.7.2-1puppetlabs1 / puppetdb: 
   4.4.0-1puppetlabs1
   - Distribution: Debian Jessie
   - Module version: latest



I have some questions about the Sensitive() function:

I've *rewritten* my config to something like this:

class profile::grafana::base (
...
  $grafana_database_password = 
Sensitive(hiera('monitoring::grafana::database::password')),
...
)
{
...
  $database_cfg = {
database => {
  type => 'mysql',
  host => "${database_server}:3306",
  name => "$grafana_database",
  user => "$grafana_database_user",
  password => $grafana_database_password.unwrap,
}
  }




The first question is: Is that correct ?

I found the password in cleartext in the PuppetDB, but I don't know, if I 
have to clear the database first, to get rid all of the sensitive values,or 
if PuppetDB removes the passwords automatically after some time.

The second question is: How looks like a plain hieradata line, to tell 
Puppet it is a sensitive value ?

For Example:

icinga2::feature::idomysql::password: 
"%{hiera('monitoring::icinga::mysql_password')}"
icinga2::feature::idomysql::database: 
"%{hiera('monitoring::icinga::mysql_db')}"

The password itself is stored in hiera-eyaml but I don't want to find it in 
the Puppetdb or logs.

Should I ask the module maintainer to support it, or is it possible to do 
it on my own?
 

cu denny

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e4896bec-0f88-4cf8-a7e7-14c49dc1c839%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetDB in EC2 , need help to configure apache reverse proxy

2017-05-01 Thread Mark_2018



*Hello Team , I am new to puppetdb I run puppet db in a EC2 instance and it 
is running and listening in port 8080*

lsof -i :8080
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
java851 puppetdb   19u  IPv6  18964  0t0  TCP localhost:webcache 
(LISTEN)


*I installed apache on the same box and configured proxy to route all the 
inbound traffic to localhost:8080*


 more reverse-proxy.conf

  ProxyRequests Off
  
Require all granted
  
   ProxyPass  / http://localhost:8081
   ProxyPassReverse  / http://localhost:8081


*when i tried to access from internet I got the below error *

Proxy Error 

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request *GET /pdb/dashboard/index.html 
*
.

Reason: *DNS lookup failure for: localhost:8081pdb*



>From Puppetdb-accesslog


localhost - - [30/Apr/2017:19:20:41 +] "GET /pdb/meta/v1/version 
HTTP/1.1" 200 25 "-" "Puppet/4.10.0 Ruby/2.1.9-p490 (x86_64-linux)" 50
127.0.0.1 - - [30/Apr/2017:20:37:36 +] "GET / HTTP/1.1" 302 0 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" 
3
127.0.0.1 - - [30/Apr/2017:20:37:41 +] "GET / HTTP/1.1" 302 0 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" 
1
127.0.0.1 - - [30/Apr/2017:20:49:50 +] "GET / HTTP/1.1" 302 0 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" 
17
127.0.0.1 - - [30/Apr/2017:21:01:32 +] "GET / HTTP/1.1" 302 0 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" 
1
127.0.0.1 - - [30/Apr/2017:21:30:25 +] "GET / HTTP/1.1" 302 0 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" 
1
127.0.0.1 - - [30/Apr/2017:21:35:40 +] "GET / HTTP/1.1" 302 0 "-" 
"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0" 
19


any help is appriciated

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/0dba8bf4-1c28-4bf6-a753-d41679fc695b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


RE: [Puppet Users] puppetdb 2.x disable some logging

2017-04-14 Thread Johan De Wit
First step i did :



added the following to logback.xml [%logger{36}]  



    /var/log/puppetdb/puppetdb.log
    true
    
    %d %-5p [%c{2}][%logger{36}] %m%n
    
    



this changed te logging to ...

2017-04-14 09:11:13,170 WARN  
[c.p.p.h.server][com.puppetlabs.puppetdb.http.server] v4 query API is 
experimental and may change without warning. For stability use the v3 api.
2017-04-14 09:11:13,179 WARN  
[c.p.p.h.event-counts][c.p.puppetdb.http.event-counts] The event-counts 
endpoint is experimental  and may be altered or removed in the future.



then I added the following to the logback.xml

    
    
    



The Api log messages are gone now, still looking how to disable the 
event-counts message.



Grts



Johan





-Original message-
From: Johan De Wit <jo...@open-future.be>
Sent: Friday 14th April 2017 8:52
To: puppet-users@googlegroups.com
Subject: [Puppet Users] puppetdb 2.x disable some logging


Hi, 

Anyone knows how to disable the logging  of follwing entries in puppetdb 2.3.8 ?

2017-04-14 08:48:07,063 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.
2017-04-14 08:48:07,065 WARN  [c.p.p.h.server] v4 query API is experimental and 
may change without warning. For stability use the v3 api.
2017-04-14 08:48:07,071 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.
2017-04-14 08:48:07,073 WARN  [c.p.p.h.server] v4 query API is experimental and 
may change without warning. For stability use the v3 api.
2017-04-14 08:48:07,079 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.
2017-04-14 08:48:07,081 WARN  [c.p.p.h.server] v4 query API is experimental and 
may change without warning. For stability use the v3 api.
2017-04-14 08:48:07,088 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.

We do need the apiv4 for some application, and above messages are eating up our 
logdisks.

I'm looking at the logback.xml, but still don't get it how to configure it ...

Thx

Johan

--
Johan De Wit

Open Source Consultant  -- Open-Future
 
Red Hat Certified Engineer   (805008667232363)
Puppet Certified Professional 2013/2014/2015/2016 (PCP006) 
Puppet Certified Instructor
blog : http://johan.koewacht.net/ <http://johan.koewacht.net/>     gsm: +32 
474 42 40 73

 

-- 
 You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
email to puppet-users+unsubscr...@googlegroups.com 
<mailto:puppet-users+unsubscr...@googlegroups.com> .
 To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/zarafa.58f07184.52ad.61916d7650418340%40zarafa7.open-future.be.
 For more options, visit https://groups.google.com/d/optout.
 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/zarafa.58f0796f.0d9b.0826204429df3f39%40zarafa7.open-future.be.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb 2.x disable some logging

2017-04-14 Thread Johan De Wit
Hi, 

Anyone knows how to disable the logging  of follwing entries in puppetdb 2.3.8 ?

2017-04-14 08:48:07,063 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.
2017-04-14 08:48:07,065 WARN  [c.p.p.h.server] v4 query API is experimental and 
may change without warning. For stability use the v3 api.
2017-04-14 08:48:07,071 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.
2017-04-14 08:48:07,073 WARN  [c.p.p.h.server] v4 query API is experimental and 
may change without warning. For stability use the v3 api.
2017-04-14 08:48:07,079 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.
2017-04-14 08:48:07,081 WARN  [c.p.p.h.server] v4 query API is experimental and 
may change without warning. For stability use the v3 api.
2017-04-14 08:48:07,088 WARN  [c.p.p.h.event-counts] The event-counts endpoint 
is experimental  and may be altered or removed in the future.

We do need the apiv4 for some application, and above messages are eating up our 
logdisks.

I'm looking at the logback.xml, but still don't get it how to configure it ...

Thx

Johan

--
Johan De Wit

Open Source Consultant  -- Open-Future
 
Red Hat Certified Engineer   (805008667232363)
Puppet Certified Professional 2013/2014/2015/2016 (PCP006) 
Puppet Certified Instructor
blog : http://johan.koewacht.net/      gsm: +32 
474 42 40 73

 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/zarafa.58f07184.52ad.61916d7650418340%40zarafa7.open-future.be.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] [PuppetDB] records not being expired from puppetdb?

2017-02-22 Thread Christopher Wood
Well that was daft of me, and you're exactly right. After applying this tuning 
older things are purged as expected. Thank you!

On Wed, Feb 22, 2017 at 01:26:45PM -0800, Wyatt Alt wrote:
> Hey Christopher,
> 
> This is the default behavior of PuppetDB -- my guess is you can address it
> by tuning your node-ttl and node-purge-ttl parameters, which are described
> here:
> 
> https://docs.puppet.com/puppetdb/latest/configure.html#node-ttl
> 
> PuppetDB won't expire or delete node data unless those parameters are set,
> and they aren't by default. The reports are deleted after 14 days by default
> (report-ttl setting), which would explain why you can see node data but no
> reports.
> 
> Wyatt
> 
> 
> On 02/21/2017 11:05 AM, Christopher Wood wrote:
> >Our security department raised that point that some nodes present in 
> >puppetdb are not for current or recently decommissioned servers.
> >
> >Does anybody have a spare hint as to why these nodes haven't become expired 
> >over the last few months of not being servers, or where I can look for more 
> >information? (PuppetDB 3.2.4.)
> >
> >More details:
> >
> >On further investigation, I can retrieve old catalogs for these nodes. The 
> >catalogs are weeks or months old, and I thought the nodes themselves might 
> >have been expired by now. Sure enough, there is nothing in the "deactivated" 
> >or "expired" fields in the certnames table in PostgreSQL for these nodes. 
> >The hosts are definitely gone as servers.
> >
> >curl --data-urlencode 'query=["=", "certname", "myhost.mydomain.com"]' -v -s 
> >-S -X GET --cacert $ca --cert $cert --key $key 
> >https://puppetdb2.mydomain.com:8081/pdb/query/v4/catalogs >/tmp/myhost.json
> >
> >I am unable to retrieve reports for these nodes (200 response from puppetdb 
> >but no actual report, '[]'). Likewise they do not appear in Puppet Explorer 
> >as nodes. (Same as above but /reports not /catalogs.)
> >
> >When I deactivated one of these nodes (puppet node deactivate) I was still 
> >able to retrieve the same old catalog that I was able to before, but this 
> >time the "deactivated" field in the certnames table was filled in.
> >
> >puppetdb=# select * from certnames where certname = 'myhost.mydomain.com';
> >-[ RECORD 1 ]+---
> >id   | 2035
> >certname | myhost.mydomain.com
> >latest_report_id |
> >deactivated  | 2017-02-21 12:28:25.495-05
> >expired  |
> >
> >We're on a slightly older version of PuppetDB (3.2.4). That said, Puppetdb 
> >has been ticking along just fine for months and this is the first problem I 
> >can remember.
> >
> >bash-4.1$ rpm -q postgresql95-server
> >postgresql95-server-9.5.0-2PGDG.rhel6.x86_64
> >
> >bash-4.1$ rpm -q puppetdb
> >puppetdb-3.2.4-1.el6.noarch
> >
> >(Also, I can't find any reference to this issue with google searches or 
> >looking on tickets.puppetlabs.com, and this is as far as I can figure out 
> >this issue.)
> >
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/709a1e9b-1a10-ef9c-2144-5728bf2527d5%40puppet.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2017015336.GA18751%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] [PuppetDB] records not being expired from puppetdb?

2017-02-22 Thread Wyatt Alt

Hey Christopher,

This is the default behavior of PuppetDB -- my guess is you can address 
it by tuning your node-ttl and node-purge-ttl parameters, which are 
described here:


https://docs.puppet.com/puppetdb/latest/configure.html#node-ttl

PuppetDB won't expire or delete node data unless those parameters are 
set, and they aren't by default. The reports are deleted after 14 days 
by default (report-ttl setting), which would explain why you can see 
node data but no reports.


Wyatt


On 02/21/2017 11:05 AM, Christopher Wood wrote:

Our security department raised that point that some nodes present in puppetdb 
are not for current or recently decommissioned servers.

Does anybody have a spare hint as to why these nodes haven't become expired 
over the last few months of not being servers, or where I can look for more 
information? (PuppetDB 3.2.4.)

More details:

On further investigation, I can retrieve old catalogs for these nodes. The catalogs are weeks or 
months old, and I thought the nodes themselves might have been expired by now. Sure enough, there 
is nothing in the "deactivated" or "expired" fields in the certnames table in 
PostgreSQL for these nodes. The hosts are definitely gone as servers.

curl --data-urlencode 'query=["=", "certname", "myhost.mydomain.com"]' -v -s -S -X 
GET --cacert $ca --cert $cert --key $key https://puppetdb2.mydomain.com:8081/pdb/query/v4/catalogs 
>/tmp/myhost.json

I am unable to retrieve reports for these nodes (200 response from puppetdb but 
no actual report, '[]'). Likewise they do not appear in Puppet Explorer as 
nodes. (Same as above but /reports not /catalogs.)

When I deactivated one of these nodes (puppet node deactivate) I was still able to 
retrieve the same old catalog that I was able to before, but this time the 
"deactivated" field in the certnames table was filled in.

puppetdb=# select * from certnames where certname = 'myhost.mydomain.com';
-[ RECORD 1 ]+---
id   | 2035
certname | myhost.mydomain.com
latest_report_id |
deactivated  | 2017-02-21 12:28:25.495-05
expired  |

We're on a slightly older version of PuppetDB (3.2.4). That said, Puppetdb has 
been ticking along just fine for months and this is the first problem I can 
remember.

bash-4.1$ rpm -q postgresql95-server
postgresql95-server-9.5.0-2PGDG.rhel6.x86_64

bash-4.1$ rpm -q puppetdb
puppetdb-3.2.4-1.el6.noarch

(Also, I can't find any reference to this issue with google searches or looking 
on tickets.puppetlabs.com, and this is as far as I can figure out this issue.)



--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/709a1e9b-1a10-ef9c-2144-5728bf2527d5%40puppet.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] [PuppetDB] records not being expired from puppetdb?

2017-02-21 Thread Christopher Wood
Our security department raised that point that some nodes present in puppetdb 
are not for current or recently decommissioned servers.

Does anybody have a spare hint as to why these nodes haven't become expired 
over the last few months of not being servers, or where I can look for more 
information? (PuppetDB 3.2.4.)

More details:

On further investigation, I can retrieve old catalogs for these nodes. The 
catalogs are weeks or months old, and I thought the nodes themselves might have 
been expired by now. Sure enough, there is nothing in the "deactivated" or 
"expired" fields in the certnames table in PostgreSQL for these nodes. The 
hosts are definitely gone as servers.

curl --data-urlencode 'query=["=", "certname", "myhost.mydomain.com"]' -v -s -S 
-X GET --cacert $ca --cert $cert --key $key 
https://puppetdb2.mydomain.com:8081/pdb/query/v4/catalogs >/tmp/myhost.json

I am unable to retrieve reports for these nodes (200 response from puppetdb but 
no actual report, '[]'). Likewise they do not appear in Puppet Explorer as 
nodes. (Same as above but /reports not /catalogs.)

When I deactivated one of these nodes (puppet node deactivate) I was still able 
to retrieve the same old catalog that I was able to before, but this time the 
"deactivated" field in the certnames table was filled in.

puppetdb=# select * from certnames where certname = 'myhost.mydomain.com';
-[ RECORD 1 ]+---
id   | 2035
certname | myhost.mydomain.com
latest_report_id | 
deactivated  | 2017-02-21 12:28:25.495-05
expired  | 

We're on a slightly older version of PuppetDB (3.2.4). That said, Puppetdb has 
been ticking along just fine for months and this is the first problem I can 
remember.

bash-4.1$ rpm -q postgresql95-server
postgresql95-server-9.5.0-2PGDG.rhel6.x86_64

bash-4.1$ rpm -q puppetdb
puppetdb-3.2.4-1.el6.noarch

(Also, I can't find any reference to this issue with google searches or looking 
on tickets.puppetlabs.com, and this is as far as I can figure out this issue.)

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/20170221190534.GA32135%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppetdb 4.3 on PG 9.4 fresh install fails to start with DB UTF8 encoding error

2017-02-17 Thread Rob Browning
s...@la-z-boy.com writes:

> java.sql.BatchUpdateException: Batch entry 1 CREATE AGGREGATE md5_agg 
> (BYTEA)
> (
>   sfunc = dual_md5,
>   stype = bytea,
>   initcond = '\x00'
> ) was aborted.  Call getNextException to see the cause.
>
> 2017-02-16 14:19:54,571 ERROR [p.p.s.migrate] Unravelled exception
> org.postgresql.util.PSQLException: ERROR: invalid byte sequence for 
> encoding "UTF8": 0x00

Hmm, I don't yet have a good idea why you're having this trouble, but as
another bit of data, I just tested that function against postgres 9.4
via psql and it worked fine, then against 8.4, and I saw something very
similar:

  $ psql -U rlb puppetdb
  psql (8.4.21)
  Type "help" for help.

  puppetdb=# create aggregate md5_agg_foo (bytea) (sfunc = dual_md5, stype = 
bytea, initcond = '\x00');
  WARNING:  nonstandard use of escape in a string literal
  LINE 1: ...bytea) (sfunc = dual_md5, stype = bytea, initcond = '\x00');
 ^
  HINT:  Use the escape string syntax for escapes, e.g., E'\r\n'.
  ERROR:  invalid byte sequence for encoding "UTF8": 0x00
  HINT:  This error can also happen if the byte sequence does not match the 
encoding expected by the server, which is controlled by "client_encoding".

But I believe puppetdb should be checking your database version before
we even get to that point via:

  
https://github.com/puppetlabs/puppetdb/blob/master/src/puppetlabs/puppetdb/scf/storage.clj#L1371

And indeed, when I try to run puppetdb against 8.4, I see this:

  * PostgreSQL DB versions older than 9.4 are no longer supported.  Please 
upgrade Postgres and restart PuppetDB.
  * 
  
  2017-02-17 16:23:09,000 ERROR [async-dispatch-2] [p.p.s.storage] 

  *
  * PostgreSQL DB versions older than 9.4 are no longer supported.  Please 
upgrade Postgres and restart PuppetDB.
  * 
  
  2017-02-17 16:23:09,007 INFO  [Thread-2] [p.t.internal] Shutting down due to 
JVM shutdown hook.
  2017-02-17 16:23:09,011 INFO  [Thread-2] [p.t.internal] Beginning shutdown 
sequence

So it does seem a bit unlikely that puppetdb is talking to a postgres
that's "too old".  Out of curiosity, does everything look reasonable
when you run

  ps aux | grep postgres

And if you take the PID for the main postgres process, something like:

  rlb  19180  1.3  0.5 2305952 82340 pts/5   S+   16:38   0:00 postgres -h 
localhost -D data

Then do you see the dir you expect for:

  ls -l /proc/19180/cwd

?

Thanks
--
Rob Browning

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/87poigmod9.fsf%40yaga.corp.puppetlabs.net.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb 4.3 on PG 9.4 fresh install fails to start with DB UTF8 encoding error

2017-02-16 Thread swk
Hi everyone,

I'm trying to do my first ever install of PuppetDB.  I'm installing 
PuppetDB 4.3 from RPM with Postgres 9.4.  When I try to start PuppetDB I 
get the following errors (removed some of the non-important java debugging 
lines):

2017-02-16 14:19:54,539 INFO  [p.p.s.migrate] Applying database migration 
version 43
2017-02-16 14:19:54,570 ERROR [p.p.s.migrate] Caught SQLException during 
migration
java.sql.BatchUpdateException: Batch entry 1 CREATE AGGREGATE md5_agg 
(BYTEA)
(
  sfunc = dual_md5,
  stype = bytea,
  initcond = '\x00'
) was aborted.  Call getNextException to see the cause.

2017-02-16 14:19:54,571 ERROR [p.p.s.migrate] Unravelled exception
org.postgresql.util.PSQLException: ERROR: invalid byte sequence for 
encoding "UTF8": 0x00


Any advice would be appreciated.  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/2ffa26d1-2cd9-41be-97cb-de446a550bcb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Puppetdb module | broken puppetdb

2016-12-28 Thread Virat
Hello,

I have used puppetdb module (https://forge.puppet.com/puppetlabs/puppetdb), 
installation went clean no errors. (rhel 7.3).Installed puppetdb separately 
(not on the puppet server) 

*Puppetdb server*

# lsof -i :8081
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
java27043 puppetdb   28u  IPv6 1481441  0t0  TCP *:tproxy (LISTEN)

# lsof -i :8080
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
java27043 puppetdb   19u  IPv6 1481433  0t0  TCP localhost:webcache 
(LISTEN)


# netstat -ltnp | grep postgres
tcp0  0 127.0.0.1:5432  0.0.0.0:*   LISTEN 
 26760/postgres
tcp6   0  0 ::1:5432:::*LISTEN 
 26760/postgres

iptables/firewall - off


*Puppet server*

below notice while executing puppetdb module on puppet server.

Notice: Unable to connect to puppetdb server 
(https://puppetdb.example.com:8081): [503] Service Unavailable
Notice: Failed to connect to puppetdb; sleeping 2 seconds before retry

*manifest *

node puppetserver.example.com {
class { 'puppetdb::master::config':
puppetdb_server => 'puppetdb.example.com',
}
}
node puppetdb.example.com {
class { 'puppetdb::database::postgresql':
listen_addresses => localhost,
}
class { 'puppetdb::server':
database_host => 'puppetdb.example.com',
}
}

*Puppetdb error logs*

http://pastebin.com/RpeCJHPf

Thank you 


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/9c093e1e-dc7f-42e9-8cd3-f22d4794348d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppetdb 4.x filling up /opt/puppetlabs/server/data/puppetdb/mq

2016-09-29 Thread Ryan Anderson
It turns out this was an ID10T error. One of my puppet masters 
inadvertently got upgraded, including the puppetserver and puppetdb-termini 
RPMs. The problem went away when I reverted the puppet RPMs back to their 
previous release. From what I could tell, the newer 
puppetserver/puppetdb-termini was sending data to the puppetdb, who did not 
appreciate the format. Classic error of using two versions of softwares not 
intended to be used with each other.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/47dcd7fe-cef5-4647-87a6-9f0312daef16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppetdb 4.x filling up /opt/puppetlabs/server/data/puppetdb/mq

2016-09-21 Thread Wyatt Alt

Hey Ryan,

At first glance this sounds like 
https://tickets.puppetlabs.com/browse/PDB-2390, but that was fixed in 
4.0.0 so it shouldn't be the issue. The fact that you have 2 gigs under 
discarded means you are sending a significant number of commands that 
PuppetDB is unable to accept. There are numerous reasons this can happen 
-- you'll probably find more info in your logs. Given that you have so 
many discards, it could be that the bloat in your scheduler directory is 
actually legitimate (malformed commands get retried, and while being 
retried they go to scheduler.


My suggestion would be to look at your PuppetDB logs and/or the files 
under discard (these will have errors in addition to the actual message) 
to figure out the problem. Post back with the errors if need be and we 
can trouble shoot from there.


Wyatt

On 9/21/16 5:28 AM, Ryan Anderson wrote:
I'm using puppetdb-4.0.0-1.el7 (open source) and over time the 
ActiveMQ part of it has been saving a bunch of logs 
under /opt/puppetlabs/server/data/puppetdb/mq, and there does not 
appear to be any built-in log rotation, at least in the version I am 
using. After using this puppetdb a couple months, this is the sizing I 
observe:


  * 6.5GB = /opt/puppetlabs/server/data/puppetdb/mq/localhost/scheduler
  * 2GB = /opt/puppetlabs/server/data/puppetdb/mq/discard


The only solution I found online is 
this: https://docs.puppet.com/puppetdb/4.2/trouble_kahadb_corruption.html. 
The workaround there is to rename the mq directory and restart 
puppetdb, but it is intended as a troubleshoot, and I am seeking to 
save disk space and avoid regular puppetdb restarts.


What files are safe to delete? Is this still a problem if I upgrade to 
puppetdb 4.2?

--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ec2b2314-cd8f-41c4-a6d6-16936ec157c9%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/64e20ffd-5802-32a6-e03b-0398574fbd94%40puppet.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb 4.x filling up /opt/puppetlabs/server/data/puppetdb/mq

2016-09-21 Thread Ryan Anderson
I'm using puppetdb-4.0.0-1.el7 (open source) and over time the ActiveMQ 
part of it has been saving a bunch of logs 
under /opt/puppetlabs/server/data/puppetdb/mq, and there does not appear to 
be any built-in log rotation, at least in the version I am using. After 
using this puppetdb a couple months, this is the sizing I observe:

   - 6.5GB = /opt/puppetlabs/server/data/puppetdb/mq/localhost/scheduler
   - 2GB = /opt/puppetlabs/server/data/puppetdb/mq/discard
   

The only solution I found online is 
this: https://docs.puppet.com/puppetdb/4.2/trouble_kahadb_corruption.html. 
The workaround there is to rename the mq directory and restart puppetdb, 
but it is intended as a troubleshoot, and I am seeking to save disk space 
and avoid regular puppetdb restarts.

What files are safe to delete? Is this still a problem if I upgrade to 
puppetdb 4.2?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ec2b2314-cd8f-41c4-a6d6-16936ec157c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] Puppetdb has not logged any new input in past 7 hours

2016-08-17 Thread Bret Wortman
My puppetdb instance is up and running but hasn't stored any updates of any 
kind in the past 7 hours, according to both Puppet Explorer and Puppetboard.

The process is running and so is postgres. Puppet configs haven't changed 
in that time. /var/log/puppetlabs/puppetdb/puppetdb.log shows plenty of 
updates coming in:

2016-08-17 16:31:48,887 INFO  [p.p.command] [-UUID-] [replace facts] 
branfile1.our.net
2016-08-17 16:31:59,136 INFO  [p.p.command] [-UUID-] [replace facts] 
zs311.our.net
2016-08-17 16:32:11,347 INFO  [p.p.command] [-UUID-] [replace facts] 
gs1205.our.net
2016-08-17 16:32:12,982 WARN  [p.p.q.engine] The event-counts entity is 
experimental and may be altered or removed in the future.
2016-08-17 16:32:15,237 INFO  [p.p.command] [-UUID-] [replace facts] 
fs1603.our.net


and so on.

There's nothing obviously wrong when Puppetdb starts up in the logfile, 
either. What should I be looking at to see why it's accepting these updates 
but (apparently) not storing them? Does anyone know postgres better than I 
do who could give me some way to directly query the database to see if one 
of the above updates (or any other, for that matter) exists?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/c447df8c-a53e-4455-b8cc-de534b9f64bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] puppetdb instllation form source

2016-07-26 Thread Wyatt Alt

Hi Joaquin,

If you're able to install with the module that's the best option by far, 
since it will handle all the configuration for you.


If something is requiring you to install from source, the instructions 
are here:

https://docs.puppet.com/puppetdb/4.1/install_from_source.html#step-2-option-a-install-from-source

Wyatt

On 7/26/16 9:39 AM, Joaquin Henriquez wrote:

Hi Guys

Trying to install puppetdb form source.
I downloaded it from git b but then what?

If I modify the puppet.conf to enable puppetdb it will lok into file 
confdir/puppetdb.conf which doesn't exist under the git version.


Doing the config.ini rename to that puppetdb.conf will need to add the 
# to few lines to comment them out.


Jetty for the puppetdb.conf (under /etc/puppetlabs/puppet) only allows 
Jetty port 8080 which even if I use "puppet master --verbose 
--no-daemonize" will not come up.
If adding to the puppetdb.conf the ssl-host and ssl-port will not work 
either as it give a parse error.


Error: Could not retrieve facts for testbedocg: Failed to find facts 
from PuppetDB at puppet:8140: undefined method `url_path' for 
Puppet::Util::Puppetdb:Module

Error: undefined method `puppet3compat?' for Puppet::Util::Puppetdb:Module


Should I install puppetdb from module or form git source?


--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b994a0ce-0736-40e9-8277-bfe5f3986284%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ababb8f3-a03a-0933-2cf5-579445f4e5e3%40puppet.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb instllation form source

2016-07-26 Thread Joaquin Henriquez
Hi Guys

Trying to install puppetdb form source.
I downloaded it from git b but then what?

If I modify the puppet.conf to enable puppetdb it will lok into file 
confdir/puppetdb.conf which doesn't exist under the git version.

Doing the config.ini rename to that puppetdb.conf will need to add the # to 
few lines to comment them out.

Jetty for the puppetdb.conf (under /etc/puppetlabs/puppet) only allows 
Jetty port 8080 which even if I use "puppet master --verbose 
--no-daemonize" will not come up.
If adding to the puppetdb.conf the ssl-host and ssl-port will not work 
either as it give a parse error.

Error: Could not retrieve facts for testbedocg: Failed to find facts from 
PuppetDB at puppet:8140: undefined method `url_path' for 
Puppet::Util::Puppetdb:Module
Error: undefined method `puppet3compat?' for Puppet::Util::Puppetdb:Module


Should I install puppetdb from module or form git source?


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b994a0ce-0736-40e9-8277-bfe5f3986284%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb general questions

2016-07-12 Thread dkoleary
Hey, all;

I've come to the point where i need to install puppetdb in my opensource 
puppet server 4.5 implementation.  

Although the use of exported resources is on the scope, the two immediate 
use cases that I'm looking for are:

   - puppet node status
   - Use of a dashboard yet TBD

I looked through the docs at https://docs.puppet.com/puppetdb/4.1/ and have 
some general questions:


   - Are there any hidden issues when installing puppetdb for use with 
   puppet server?  The doc mentions puppet master repeatedly.  I'm not seeing 
   anything in any of the docs that look like they wouldn't run on puppet 
   server 4.5.  Even the "puppet master --configprint route_file" works but 
   having direct feedback from someone who's done it would be nice.
   - When should I consider installing puppetdb on a separate node?  I have 
   8 very basic modules managing roughly 1200 linux systems.  The puppet 
   server is a physical HP dl360 gen8 w/2x16 core cpus and 32 gigs of ram. 
The number of modules will increase as we migrate more fully into the 
   puppet management paradigm and we will probably end up with nigh on 2000 
   nodes by year's end.  We may also have other teams using open source puppet 
   if the long-delayed puppet enterprise is delayed yet again; however, for 
   the moment, the implementation is very low impact.
   - If I do install puppetdb on the puppet server, how hard is it to move 
   if I later decide to split them up?

I think that covers the questions.  Any hints/tips/suggestions on avoiding 
hurdles would be greatly appreciated as well.  

Thanks for your time

Doug O'Leary

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/595d957c-f360-49d5-b2dc-e39f56e85cae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Mike Sharpton
I was messing around in psql to see if I could figure out the table 
structure and just query without the API wrapper, I couldn't before you 
replied.  Price is right losing horn.

On Friday, June 3, 2016 at 1:37:59 PM UTC-5, Mike Sharpton wrote:
>
> Doh!  Quotes matter, didn't think of it.  That appears to work, I grepped 
> and piped and have my list.  Thanks very much again, you have saved me work 
> twice now.  
>
> Mike
>
> On Friday, June 3, 2016 at 12:43:17 PM UTC-5, Wyatt Alt wrote:
>>
>> Mike,
>>
>> Where I was going with that is you might get results with
>>
>> curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and", 
>> ["=", ["fact", "operatingsystemmajrelease"], "7"], ["=", ["fact", "facta"], 
>> "true"]]'
>>
>> or
>>
>> curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and", 
>> ["=", ["fact", "operatingsystemmajrelease"], "7"], ["=", ["fact", "facta"], 
>> "True"]]'
>>
>> Let me know if one of those does it.
>>
>> Wyatt
>>
>>
>> On Fri, Jun 3, 2016 at 10:37 AM, Mike Sharpton  wrote:
>>
>>> Yep, the value of my fact is a string.  I will keep googling around to 
>>> see what I can find.  Thanks,
>>>
>>> Mike
>>>
>>>
>>> On Friday, June 3, 2016 at 11:31:28 AM UTC-5, Wyatt Alt wrote:

 Hey Mike, 

 I think operatingsystemmajrelease might be a string instead of an int, 
 based on https://tickets.puppetlabs.com/browse/FACT-962. You also 
 might 
 verify that facta is valued with a real boolean instead of a 
 stringified 
 bool (the reference to casing made me wonder.) 

 Wyatt 

>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to puppet-users...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/puppet-users/08f94fe4-c922-4ead-aced-400212c7a058%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/95fc0dbb-8c04-441f-97b3-1da4841b7f4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Mike Sharpton
Doh!  Quotes matter, didn't think of it.  That appears to work, I grepped 
and piped and have my list.  Thanks very much again, you have saved me work 
twice now.  

Mike

On Friday, June 3, 2016 at 12:43:17 PM UTC-5, Wyatt Alt wrote:
>
> Mike,
>
> Where I was going with that is you might get results with
>
> curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and", 
> ["=", ["fact", "operatingsystemmajrelease"], "7"], ["=", ["fact", "facta"], 
> "true"]]'
>
> or
>
> curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and", 
> ["=", ["fact", "operatingsystemmajrelease"], "7"], ["=", ["fact", "facta"], 
> "True"]]'
>
> Let me know if one of those does it.
>
> Wyatt
>
>
> On Fri, Jun 3, 2016 at 10:37 AM, Mike Sharpton  > wrote:
>
>> Yep, the value of my fact is a string.  I will keep googling around to 
>> see what I can find.  Thanks,
>>
>> Mike
>>
>>
>> On Friday, June 3, 2016 at 11:31:28 AM UTC-5, Wyatt Alt wrote:
>>>
>>> Hey Mike, 
>>>
>>> I think operatingsystemmajrelease might be a string instead of an int, 
>>> based on https://tickets.puppetlabs.com/browse/FACT-962. You also might 
>>> verify that facta is valued with a real boolean instead of a stringified 
>>> bool (the reference to casing made me wonder.) 
>>>
>>> Wyatt 
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/08f94fe4-c922-4ead-aced-400212c7a058%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3419859f-6b0b-4a70-adad-4e910fa7c74f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Mike Sharpton
Yep, the value of my fact is a string.  I will keep googling around to see 
what I can find.  Thanks,

Mike

On Friday, June 3, 2016 at 11:31:28 AM UTC-5, Wyatt Alt wrote:
>
> Hey Mike, 
>
> I think operatingsystemmajrelease might be a string instead of an int, 
> based on https://tickets.puppetlabs.com/browse/FACT-962. You also might 
> verify that facta is valued with a real boolean instead of a stringified 
> bool (the reference to casing made me wonder.) 
>
> Wyatt 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/08f94fe4-c922-4ead-aced-400212c7a058%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Wyatt Alt
Mike,

Where I was going with that is you might get results with

curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and",
["=", ["fact", "operatingsystemmajrelease"], "7"], ["=", ["fact", "facta"],
"true"]]'

or

curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and",
["=", ["fact", "operatingsystemmajrelease"], "7"], ["=", ["fact", "facta"],
"True"]]'

Let me know if one of those does it.

Wyatt


On Fri, Jun 3, 2016 at 10:37 AM, Mike Sharpton  wrote:

> Yep, the value of my fact is a string.  I will keep googling around to see
> what I can find.  Thanks,
>
> Mike
>
>
> On Friday, June 3, 2016 at 11:31:28 AM UTC-5, Wyatt Alt wrote:
>>
>> Hey Mike,
>>
>> I think operatingsystemmajrelease might be a string instead of an int,
>> based on https://tickets.puppetlabs.com/browse/FACT-962. You also might
>> verify that facta is valued with a real boolean instead of a stringified
>> bool (the reference to casing made me wonder.)
>>
>> Wyatt
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/08f94fe4-c922-4ead-aced-400212c7a058%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAJDiH3FAaY40bD_ZYgSP0QNY3znz83Wto7rdD2dZk7y2erYCCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Mike Sharpton
Wyatt,

Thanks for your reply.  I changed out my url and facta to my fact name, 
nothing is returned except this.

[ ]

To ensure it wasn't my fact that was messing this up, I tried another 
standard fact is_pe.  The value should be uppercase "False" but this 
returns a 500 when run that post/GET.

:8080/pdb/query/v4/nodes -d 'query=["and", ["=", ["fact", 
"operatingsystemmajrelease"], 7], ["=", ["fact", "is_pe"], False]]'

This returns nothing as well.  I have about 350 nodes of this type.

:8080/pdb/query/v4/nodes -d 'query=["and", ["=", ["fact", 
"operatingsystemmajrelease"], 7], ["=", ["fact", "is_pe"], false]]'

My fact value is lowercase as well, true is the value.  Any ideas?  

Thanks in advance,
Mike



On Friday, June 3, 2016 at 9:56:41 AM UTC-5, Wyatt Alt wrote:
>
> Hey Mike,
> I'm thinking you want something like this:
>
> curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and", 
> ["=", ["fact", "operatingsystemmajrelease"], 7], ["=", ["fact", "facta"], 
> true]]'
>
> Wyatt
>
>
>
> On Fri, Jun 3, 2016 at 6:40 AM, Mike Sharpton  > wrote:
>
>> Hey all,
>>
>> I am trying to do what should be a simple thing.  I need to query 
>> PuppetDB to gather a list of machines based on arbitrary facta being equal 
>> to true and the operatingsystemmajrelease fact being 7.  I have searched 
>> around and found a few examples, but can't get them to work properly.  I 
>> saw and example from Wyatt on here, but I must be doing something wrong as 
>> I can't even get that to run.  I have PuppetDB 3.2.0.
>>
>> I'm not sure if I should be running my query against this endpoint 
>> /pdb/query/v4/facts/, or drill into the facta uri and run a in/and against 
>> the operatingsystemmajrelease fact to get what I need.  All I need back is 
>> the certname of the machines in which facta is true and 
>> operatingsystemmajrelease is 7.  If someone has a quick one liner, it would 
>> be appreciated, otherwise I can bust out the data and filter it with 
>> Excel.  Thanks,
>>
>> Mike
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-users...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/5a1fec0e-1d02-442f-9465-9660a6087a8f%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5560a1c7-b2a9-482c-a1cd-e493b3dad2b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Wyatt Alt
Hey Mike,
I'm thinking you want something like this:

curl -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["and",
["=", ["fact", "operatingsystemmajrelease"], 7], ["=", ["fact", "facta"],
true]]'

Wyatt



On Fri, Jun 3, 2016 at 6:40 AM, Mike Sharpton  wrote:

> Hey all,
>
> I am trying to do what should be a simple thing.  I need to query PuppetDB
> to gather a list of machines based on arbitrary facta being equal to true
> and the operatingsystemmajrelease fact being 7.  I have searched around and
> found a few examples, but can't get them to work properly.  I saw and
> example from Wyatt on here, but I must be doing something wrong as I can't
> even get that to run.  I have PuppetDB 3.2.0.
>
> I'm not sure if I should be running my query against this endpoint
> /pdb/query/v4/facts/, or drill into the facta uri and run a in/and against
> the operatingsystemmajrelease fact to get what I need.  All I need back is
> the certname of the machines in which facta is true and
> operatingsystemmajrelease is 7.  If someone has a quick one liner, it would
> be appreciated, otherwise I can bust out the data and filter it with
> Excel.  Thanks,
>
> Mike
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/5a1fec0e-1d02-442f-9465-9660a6087a8f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAJDiH3HK%3DihNjuz8PGWcKM_XsQsHcQ46DCqBw-o8etY8uG-JpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB Query based on facts

2016-06-03 Thread Mike Sharpton
Hey all,

I am trying to do what should be a simple thing.  I need to query PuppetDB 
to gather a list of machines based on arbitrary facta being equal to true 
and the operatingsystemmajrelease fact being 7.  I have searched around and 
found a few examples, but can't get them to work properly.  I saw and 
example from Wyatt on here, but I must be doing something wrong as I can't 
even get that to run.  I have PuppetDB 3.2.0.

I'm not sure if I should be running my query against this endpoint 
/pdb/query/v4/facts/, or drill into the facta uri and run a in/and against 
the operatingsystemmajrelease fact to get what I need.  All I need back is 
the certname of the machines in which facta is true and 
operatingsystemmajrelease is 7.  If someone has a quick one liner, it would 
be appreciated, otherwise I can bust out the data and filter it with Excel. 
 Thanks,

Mike

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5a1fec0e-1d02-442f-9465-9660a6087a8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB resources are not available

2016-05-31 Thread Harish Kothuri
Hi Wyatt,

I now have a custom fact using powershell commands to get the installed 
software's for windows machines.

*PS Command:-* 
Get-ItemProperty 
HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | 
where{$_.DisplayName -and $_.displayname -notmatch 'Update'} | 
Select-Object DisplayName, DisplayVersion | ForEach-Object {Write-Host 
$_.DisplayName"="$_.DisplayVersion}

*Output:-*
ActiveState ActiveTcl 8.4.20.0 = 8.4.20.0
Microsoft .NET Framework 4 Client Profile = 4.0.30319
Microsoft .NET Framework 4 Extended = 4.0.30319
Notepad++ = 6.9.1
Microsoft .NET Framework 4 Extended = 4.0.30319
Puppet = 3.8.7
Microsoft Visual C++ 2012 Redistributable (x86) - 11.0.61030 = 11.0.61030.0
Microsoft .NET Framework 4 Client Profile = 4.0.30319
MSXML 4.0 SP2 Parser and SDK = 4.20.9818.0
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17 = 9.0.30729
VC9.0 SP0 Debug CRT DLLs = 1.0.0
Microsoft Visual C++ 2012 x86 Additional Runtime - 11.0.61030 = 11.0.61030
Microsoft Visual C++ 2012 x86 Minimum Runtime - 11.0.61030 = 11.0.61030
Microsoft Visual C++ 2010  x86 Redistributable - 10.0.40219 = 10.0.40219
ActivePerl 5.16.3 Build 1603 = 5.16.1603

Thanks,
Harish

On Thursday, May 19, 2016 at 1:11:17 AM UTC+5:30, Wyatt Alt wrote:
>
> Harish,
>
> The reason for that is the resources returned by puppet resource come from 
> the RAL, rather than PuppetDB. If you were to declare puppet resources with 
> the content included in your paste, then they would show up in PuppetDB. 
>
> PuppetDB will only include version information on package resources if the 
> package is managed by puppet and the version is specified in the resource 
> declaration. The most straightforward way to get information on all 
> packages installed (e.g not managed by Puppet) into PuppetDB is to create a 
> custom fact. I saw a module posted to the forge to do this the other day: 
> https://forge.puppet.com/rmueller/pkg_inventory
>
> Looks like it currently supports only redhat but if you're on something 
> else you should be able to get an idea of how to adapt it based on the fact 
> defined here: 
> https://github.com/roman-mueller/rmueller-pkg_inventory/blob/master/lib/facter/pkg_inventory.rb
>  
> .
>
> Given the fact you could get the data by querying 
> localhost:8080/v4/facts/packages, assuming the name of the fact is 
> "packages".
>
> Hope that helps.
>
> Wyatt
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b2d8ef64-438f-46da-8385-390378591198%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB resources are not available

2016-05-18 Thread Wyatt Alt
Harish,

The reason for that is the resources returned by puppet resource come from
the RAL, rather than PuppetDB. If you were to declare puppet resources with
the content included in your paste, then they would show up in PuppetDB.

PuppetDB will only include version information on package resources if the
package is managed by puppet and the version is specified in the resource
declaration. The most straightforward way to get information on all
packages installed (e.g not managed by Puppet) into PuppetDB is to create a
custom fact. I saw a module posted to the forge to do this the other day:
https://forge.puppet.com/rmueller/pkg_inventory

Looks like it currently supports only redhat but if you're on something
else you should be able to get an idea of how to adapt it based on the fact
defined here:
https://github.com/roman-mueller/rmueller-pkg_inventory/blob/master/lib/facter/pkg_inventory.rb
.

Given the fact you could get the data by querying
localhost:8080/v4/facts/packages, assuming the name of the fact is
"packages".

Hope that helps.

Wyatt

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAJDiH3FrcyX9-BV9jSOocbi3V_4NAfBg9zNJsCTz5F%2BBSrD7rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB resources are not available

2016-05-18 Thread Harish Kothuri
Hi Wyatt,

Thanks for your quick reply !

I do get some response for /v3/resources/Package , but it does not contain 
any information about software's installed on node and it's versions. 

My data of interest is similar to following ( I got this from node when i 
issue *"puppet resource package"*) . Please help.

package { 'Notepad++':
  ensure => '6.9.1',
}
package { 'Puppet':
  ensure => '3.8.7',
}
package { 'Realtek Ethernet Controller Driver':
  ensure => '7.87.529.2014',
}

Thanks

On Thursday, May 19, 2016 at 12:16:13 AM UTC+5:30, Wyatt Alt wrote:
>
> Hey Harish,
>
> Your issue could be that trailing backslash. PuppetDB is likely 
> interpretting it as a query for all resources with type "" (i.e empty 
> string).
>
> You should be able to get all package resources with 
> /v3/resources/Package, and you can restrict that to a given node with
>
> curl -X GET http://:8080/v3/resources/Package -d 
> 'query=["=","certname","example.com"]'
>
> Wyatt
>
>
>
> On 05/18/2016 11:08 AM, Harish Kothuri wrote:
>
> Hi Ken, 
>
> Thanks for your reply.
>
> I got the resource and catalog endpoints working after changing the 
> confdir ownership with " sudo chown -R puppet:puppet `sudo puppet config 
> print confdir`".
>
> Now, i just need to get the resource list for all machines or for a 
> specific machine. I can't seem to find the resource/package list from " 
> http://sdin-swt-ctf-01:8080/v3/resources/; 
>
> Plz help.
>
> Thanks
>
> On Wednesday, May 18, 2016 at 6:47:17 PM UTC+5:30, Ken Barber wrote: 
>>
>> So at a high level  
>>
>> The resources are populated from successful Puppet runs that submit 
>> their catalogs to PuppetDB. So step 1, run puppet agent -t or 
>> whatever, if you aren't seeing something like this in your 
>> puppetdb.log: 
>>
>> 2016-05-18 14:12:28,855 INFO  [command-proc-3055] [p.p.command] 
>> [898d1f2d-f96b-450f-a627-7fb90eb7d491] [replace catalog] 
>> macbook-pro-9.lan 
>>
>> Then the connection between puppet master & puppetdb is not configured 
>> correctly, these instructions cover that: 
>>
>> https://docs.puppet.com/puppetdb/4.0/connect_puppet_master.html 
>>
>> (adjust for your version of PuppetDB, which looks like its a 2.x to me) 
>>
>> You should also check your puppet master logs to see if there are any 
>> errors while submitting the catalog. 
>>
>> ken. 
>>
>> On Wed, May 18, 2016 at 7:21 AM, Harish Kothuri  
>> wrote: 
>> > Hi, 
>> > 
>> > I am trying to access resources from PuppetDB API as follows, API makes 
>> a 
>> > successful call but empty response. 
>> > 
>> > API call: 
>> > curl -X GET 'http://sdin-swt-ctf-01:8080/v3/resources/' 
>> > 
>> > Ouput: 
>> > [ ] 
>> > 
>> > Is there anything that i need to enable to populate the same? 
>> > 
>> > 
>> > Thanks 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "Puppet Users" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to puppet-users...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/puppet-users/ca08dcc7-f58b-462e-b9ab-6c6dd5610fe8%40googlegroups.com.
>>  
>>
>> > For more options, visit https://groups.google.com/d/optout. 
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit 
> 
> https://groups.google.com/d/msgid/puppet-users/69a5f06d-374d-4229-9cab-9bbd98e1c4f5%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f51215df-1364-4f51-9c5a-7c7d9f15e069%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB resources are not available

2016-05-18 Thread Wyatt Alt

Hey Harish,

Your issue could be that trailing backslash. PuppetDB is likely 
interpretting it as a query for all resources with type "" (i.e empty 
string).


You should be able to get all package resources with 
/v3/resources/Package, and you can restrict that to a given node with


curl -X GET http://:8080/v3/resources/Package -d 
'query=["=","certname","example.com"]'


Wyatt



On 05/18/2016 11:08 AM, Harish Kothuri wrote:

Hi Ken,

Thanks for your reply.

I got the resource and catalog endpoints working after changing the 
confdir ownership with " sudo chown -R puppet:puppet `sudo puppet 
config print confdir`".


Now, i just need to get the resource list for all machines or for a 
specific machine. I can't seem to find the resource/package list from 
" http://sdin-swt-ctf-01:8080/v3/resources/;


Plz help.

Thanks

On Wednesday, May 18, 2016 at 6:47:17 PM UTC+5:30, Ken Barber wrote:

So at a high level 

The resources are populated from successful Puppet runs that submit
their catalogs to PuppetDB. So step 1, run puppet agent -t or
whatever, if you aren't seeing something like this in your
puppetdb.log:

2016-05-18 14:12:28,855 INFO  [command-proc-3055] [p.p.command]
[898d1f2d-f96b-450f-a627-7fb90eb7d491] [replace catalog]
macbook-pro-9.lan

Then the connection between puppet master & puppetdb is not
configured
correctly, these instructions cover that:

https://docs.puppet.com/puppetdb/4.0/connect_puppet_master.html


(adjust for your version of PuppetDB, which looks like its a 2.x
to me)

You should also check your puppet master logs to see if there are any
errors while submitting the catalog.

ken.

On Wed, May 18, 2016 at 7:21 AM, Harish Kothuri
 wrote:
> Hi,
>
> I am trying to access resources from PuppetDB API as follows,
API makes a
> successful call but empty response.
>
> API call:
> curl -X GET 'http://sdin-swt-ctf-01:8080/v3/resources/
'
>
> Ouput:
> [ ]
>
> Is there anything that i need to enable to populate the same?
>
>
> Thanks
>
> --
> You received this message because you are subscribed to the
Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from
it, send an
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit
>

https://groups.google.com/d/msgid/puppet-users/ca08dcc7-f58b-462e-b9ab-6c6dd5610fe8%40googlegroups.com

.

> For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to puppet-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/69a5f06d-374d-4229-9cab-9bbd98e1c4f5%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ef1cf576-d3f1-dfa6-6c6f-8d9a8a33ece6%40puppet.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB resources are not available

2016-05-18 Thread Harish Kothuri
Hi Ken,

Thanks for your reply.

I got the resource and catalog endpoints working after changing the confdir 
ownership with " sudo chown -R puppet:puppet `sudo puppet config print 
confdir`".

Now, i just need to get the resource list for all machines or for a 
specific machine. I can't seem to find the resource/package list from 
" http://sdin-swt-ctf-01:8080/v3/resources/; 

Plz help.

Thanks

On Wednesday, May 18, 2016 at 6:47:17 PM UTC+5:30, Ken Barber wrote:
>
> So at a high level  
>
> The resources are populated from successful Puppet runs that submit 
> their catalogs to PuppetDB. So step 1, run puppet agent -t or 
> whatever, if you aren't seeing something like this in your 
> puppetdb.log: 
>
> 2016-05-18 14:12:28,855 INFO  [command-proc-3055] [p.p.command] 
> [898d1f2d-f96b-450f-a627-7fb90eb7d491] [replace catalog] 
> macbook-pro-9.lan 
>
> Then the connection between puppet master & puppetdb is not configured 
> correctly, these instructions cover that: 
>
> https://docs.puppet.com/puppetdb/4.0/connect_puppet_master.html 
>
> (adjust for your version of PuppetDB, which looks like its a 2.x to me) 
>
> You should also check your puppet master logs to see if there are any 
> errors while submitting the catalog. 
>
> ken. 
>
> On Wed, May 18, 2016 at 7:21 AM, Harish Kothuri  > wrote: 
> > Hi, 
> > 
> > I am trying to access resources from PuppetDB API as follows, API makes 
> a 
> > successful call but empty response. 
> > 
> > API call: 
> > curl -X GET 'http://sdin-swt-ctf-01:8080/v3/resources/' 
> > 
> > Ouput: 
> > [ ] 
> > 
> > Is there anything that i need to enable to populate the same? 
> > 
> > 
> > Thanks 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "Puppet Users" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to puppet-users...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/puppet-users/ca08dcc7-f58b-462e-b9ab-6c6dd5610fe8%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/69a5f06d-374d-4229-9cab-9bbd98e1c4f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB resources are not available

2016-05-18 Thread Ken Barber
So at a high level 

The resources are populated from successful Puppet runs that submit
their catalogs to PuppetDB. So step 1, run puppet agent -t or
whatever, if you aren't seeing something like this in your
puppetdb.log:

2016-05-18 14:12:28,855 INFO  [command-proc-3055] [p.p.command]
[898d1f2d-f96b-450f-a627-7fb90eb7d491] [replace catalog]
macbook-pro-9.lan

Then the connection between puppet master & puppetdb is not configured
correctly, these instructions cover that:

https://docs.puppet.com/puppetdb/4.0/connect_puppet_master.html

(adjust for your version of PuppetDB, which looks like its a 2.x to me)

You should also check your puppet master logs to see if there are any
errors while submitting the catalog.

ken.

On Wed, May 18, 2016 at 7:21 AM, Harish Kothuri  wrote:
> Hi,
>
> I am trying to access resources from PuppetDB API as follows, API makes a
> successful call but empty response.
>
> API call:
> curl -X GET 'http://sdin-swt-ctf-01:8080/v3/resources/'
>
> Ouput:
> [ ]
>
> Is there anything that i need to enable to populate the same?
>
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/ca08dcc7-f58b-462e-b9ab-6c6dd5610fe8%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAE4bNT%3D--8V37as-PiLLYuV%2BLu3ZjSJypO-HdSR_pToPAirn4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] PuppetDB resources are not available

2016-05-18 Thread Harish Kothuri
Hi,

I am trying to access resources from PuppetDB API as follows, API makes a 
successful call but empty response.

*API call:*
curl -X GET 'http://sdin-swt-ctf-01:8080/v3/resources/'

*Ouput:*
[ ]

Is there anything that i need to enable to populate the same?


Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ca08dcc7-f58b-462e-b9ab-6c6dd5610fe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[Puppet Users] puppetdb database size

2016-04-29 Thread Angel L. Mateo

Hello,

I'm running puppetdb (2.3.8 for compatibility with puppet 3.8) for a 
time.

	I have observed that although I don't significantly increase the number 
of servers, the size used by its database is constantly growing, not a 
lot, but continuously.


Is this normal? Or maybe am I missing some maintenance task?

--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868887590
Fax: 86337

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/5722FAAA.4010908%40um.es.
For more options, visit https://groups.google.com/d/optout.


Re: [Puppet Users] PuppetDB Issue with large array-valued fact

2016-04-26 Thread Mike Sharpton
Thanks Wyatt, I dropped it a while back after realizing how easy this was. 
 All is back now, and metrics are returning to normal.  The large facts are 
now gone and so are our issues.  :-)  I was wrong on the GC, it's at the 
default of one hour.  I was thinking node-ttl, which we set to 1 week. 
 Thanks again, case closed.

On Tuesday, April 26, 2016 at 3:49:13 PM UTC-5, Wyatt Alt wrote:
>
> Mike, 
>
> If you have no issue dropping and recreating the full database, that's 
> totally a workaround here (you know your requirements better than I, so 
> please don't take this as an endorsement of the approach :-) ). 
>
> To do this just stop PuppetDB, drop the puppetdb database, and recreate 
> the database with the options you want (the usual ones are described 
> here, but some people use different: 
> https://docs.puppet.com/puppetdb/latest/configure.html#using-postgresql), 
> and restart PuppetDB. 
>
> PuppetDB won't recreate the database for you but once that's in place 
> it'll create the tables/indices on startup. You may also consider 
> setting gc-interval to something less than 1 week, unless there's a good 
> reason for it being so long. A one-week interval will allow a lot of 
> time for bloat to build up. 
>
> Wyatt 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ef981bb8-6615-43fb-887b-ab3e2547a45b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   4   5   6   >