[Puppet Users] Running multile MySQL Instances on the same server
Was wondering if someone has implemented the management of multiple MySQL instances using puppet on the same server? Essentially we want to use the same MySQL binaries but implement multiple distinct MySQL instances connecting via a specific port number. Puppet Forge has a great MySQL implementation including databases, users and permissions but it doesn't seem to allow for managing multiple instances. Any information would be greatly 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
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] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Hi Mike, thanks for the reply. I'll look at the doci and see what they say but somehow I suspected that. And thanks for how to disable puppetdb. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/35fa7053-7868-496d-bc07-f1e4e6378104%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
I looked at both documents and the second one references the scheduler log files filling up. Mine are actually in the KahaDB directory. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/b74af519-6426-4acf-96eb-329ebe0cabdc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Open Source PuppetDB Code
I did a little searching on github but couldn't find it. Does anyone know where the source code is for the PuppetDB server? I'm really looking for the source code that contains the DML (insert, select, update, delete). 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/07a704c4-563b-492c-b08d-e817e78bc113%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Apparently the size of a response is limited and it cut off the rest of my message. Here are some others: < 2017-06-30 07:32:05.255 EDT >LOG: duration: 1220.789 ms execute S_6773/C_6774: SELECT fs.certname AS certname, env.name AS environment, fp.name AS name, fv.value AS value FROM factsets fs INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_values fv ON f.fact_value_id = fv.id INNER JOIN fact_paths fp ON f.fact_path_id = fp. id INNER JOIN value_types vt ON vt.id = fv.value_type_id LEFT JOIN environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND ((fs.certname = $1) AND ((fs.c ertname) in ( (SELECT certnames.certname AS certname FROM certnames LEFT JOIN catalogs ON certnames.certname = catalogs.certname LEFT JOIN factsets fs ON certnames.cer tname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND (reports.id in (SELECT latest_report_id FROM certnames))) LEFT JOIN environments cat alog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN envi ronments reports_environment ON reports_environment.id = reports.environment_id WHERE (certnames.deactivated IS NULL AND certnames.expired IS NULL)) ) ))) < 2017-06-30 07:32:05.255 EDT >DETAIL: parameters: $1 = 'xbpmrxm2s.aetna.com' < 2017-06-30 07:32:05.374 EDT >LOG: duration: 1131.477 ms execute S_6907/C_6908: SELECT fs.certname AS certname, env.name AS environment, fp.name AS name, fv.value AS value FROM factsets fs INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_values fv ON f.fact_value_id = fv.id INNER JOIN fact_paths fp ON f.fact_path_id = fp. id INNER JOIN value_types vt ON vt.id = fv.value_type_id LEFT JOIN environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND ((fs.certname = $1) AND ((fs.c ertname) in ( (SELECT certnames.certname AS certname FROM certnames LEFT JOIN catalogs ON certnames.certname = catalogs.certname LEFT JOIN factsets fs ON certnames.cer tname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND (reports.id in (SELECT latest_report_id FROM certnames))) LEFT JOIN environments cat alog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN envi ronments reports_environment ON reports_environment.id = reports.environment_id WHERE (certnames.deactivated IS NULL AND certnames.expired IS NULL)) ) ))) < 2017-06-30 07:32:05.374 EDT >DETAIL: parameters: $1 = 'xiibw2d.aetna.com' < 2017-06-30 07:32:05.391 EDT >LOG: duration: 1063.130 ms execute S_7083/C_7084: SELECT fs.certname AS certname, env.name AS environment, fp.name AS name, fv.value AS value FROM factsets fs INNER JOIN facts f ON fs.id = f.factset_id INNER JOIN fact_values fv ON f.fact_value_id = fv.id INNER JOIN fact_paths fp ON f.fact_path_id = fp. id INNER JOIN value_types vt ON vt.id = fv.value_type_id LEFT JOIN environments env ON fs.environment_id = env.id WHERE (fp.depth = 0 AND ((fs.certname = $1) AND ((fs.c ertname) in ( (SELECT certnames.certname AS certname FROM certnames LEFT JOIN catalogs ON certnames.certname = catalogs.certname LEFT JOIN factsets fs ON certnames.cer tname = fs.certname LEFT JOIN reports ON (certnames.certname = reports.certname AND (reports.id in (SELECT latest_report_id FROM certnames))) LEFT JOIN environments cat alog_environment ON catalog_environment.id = catalogs.environment_id LEFT JOIN environments facts_environment ON facts_environment.id = fs.environment_id LEFT JOIN envi ronments reports_environment ON reports_environment.id = reports.environment_id WHERE (certnames.deactivated IS NULL AND certnames.expired IS NULL)) ) ))) < 2017-06-30 07:32:05.391 EDT >DETAIL: parameters: $1 = 'xbpmsbw1q.aetna.com' Also seeing: < 2017-06-30 07:47:49.604 EDT >LOG: checkpoints are occurring too frequently (19 seconds apart) < 2017-06-30 07:47:49.604 EDT >HINT: Consider increasing the configuration parameter "checkpoint_segments". I've already increased that to 32. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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 >
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Some additional messages: < 2017-06-30 07:47:50.265 EDT >LOG: incomplete message from client < 2017-06-30 07:47:52.052 EDT >LOG: incomplete message from client < 2017-06-30 07:47:54.125 EDT >LOG: incomplete message from client < 2017-06-30 07:47:54.545 EDT >LOG: incomplete message from client < 2017-06-30 07:48:02.343 EDT >LOG: incomplete message from client < 2017-06-30 07:48:04.957 EDT >LOG: incomplete message from client < 2017-06-30 07:48:05.256 EDT >LOG: incomplete message from client On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/bbf0ec45-d406-4fad-b772-98199e988ee7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
120 = '68664231', $121 = '537', $122 = '257', $123 = '68711523', $124 = '537', $125 = '388', $126 = '68711510', $127 = '537', $128 = '250', $129 = '68711522', $130 = '537', $131 = '97', $132 = '68711506', $133 = '537', $134 = '43906', $135 = '46742800', $136 = '537', $137 = '1286', $138 = '68711508', $139 = '537', $140 = '325', $141 = '67891543', $142 = '537', $143 = '336', $144 = '68711522', $145 = '537', $146 = '43908', $147 = '68711518', $148 = '537', $149 = '737', $150 = '53900313', $151 = '537', $152 = '799', $153 = '68711516', $154 = '537', $155 = '43918', $156 = '68711526', $157 = '537', $158 = '759', $159 = '68542183', $160 = '537', $161 = '385', $162 = '67552962', $163 = '537', $164 = '1277', $165 = '68584328', $166 = '537', $167 = '4', $168 = '67552961', $169 = '537', $170 = '192', $171 = '68711511', $172 = '537', $173 = '1273', $174 = '68711521', $175 = '537', $176 = '794', $177 = '68664249', $178 = '537', $179 = '43873', $180 = '68584345', $181 = '537', $182 = '895', $183 = '68711517', $184 = '537', $185 = '104', $186 = '640285', $187 = '537', $188 = '321', $189 = '68711514', $190 = '537', $191 = '911', $192 = '68711520', $193 = '537', $194 = '47201', $195 = '68653160', $196 = '537', $197 = '1284', $198 = '65529523', $199 = '537', $200 = '1294', $201 = '68584343', $202 = '537', $203 = '210', $204 = '68711525', $205 = '537', $206 = '176', $207 = '68711513', $208 = '537', $209 = '711', $210 = '64276521', $211 = '537', $212 = '43921', $213 = '13740347', $214 = '537', $215 = '43852', $216 = '68711509', $217 = '537', $218 = '1299', $219 = '24482470', $220 = '537', $221 = '109', $222 = '67891543', $223 = '537', $224 = '706', $225 = '68711507' On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/cf08f713-ad6d-4e63-b07d-4c3dd3fdfbe1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
So if I'm reading this correctly, the userlist#~(number) represents the value of the userlist fact? If that is the case, the size of the userlist fact is 228k each and every time puppet agent runs with approximately 3300 nodes. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/814883b8-9077-48b8-a94a-42865881f94d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Well we do know where the user list is being generated and the module that is pulling the active directory list. Out of the thousands of id's only 10 are being used so the module owner is rewriting it. This does provide some confirmation of our theory. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/7f757f2a-0f2e-45ba-9c18-8dccc214bae8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
What is the actual definition of store_usage? It's not very specific. Does it limit the number of KahaDB logs? If so what happens when that limit is reached? On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/eab67fff-269e-40fe-80c6-5c7a8f135387%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
So after a change from the module owner who's fact's were very very large, the java CPU has been reduced significantly and running much better. However, now that the facts have changed for every single node, the DB is doing a significant amount of work to clean things up. And the KahaDB queue is still growing out of control. At this point it might be a better option to stop the puppetdb server, shutdown postgresql, delete the data directory (after copying pg_hba.conf and postgresql.conf to /tmp), init a new db, copy those 2 files from /tmp back to their original spot, start postgresql and start puppetdb allowing it to create everything it needs from scratch. Any opinions? On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/42d78acf-727e-406f-a2c1-f6253121991b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Chris that is this my take on historical data as well. We have processes that export the data to a data warehouse for consumption by other apps. Missing some won't kill that process, like the data never existed. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/04350a71-df08-4745-b3fc-1578359c92bd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Well after several attempts at tuning the DB config and puppetdb config, we had to drop the postgresql database and recreate it then allowing puppetdb to create the required tables, indexes, etc. Now the command queue is going between zero and four, processed tens of thousands of queue commands (since restarting at 10:15am) and the cpu load on the server is next to nothing. My guess is the database was corrupt somehow with all of the deletes from the KahaDB directory plus trying to remove a huge amount of facts. I think puppet needs to provide some type of DB reset process without have to drop/create the DB. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/27a1ac7d-d024-4489-bac8-77f41080d80f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Compare node fact runs
I'm seeing a lot of replace facts in the puppetdb server log. I googled but can't find anything solid. Is there a way to compare facts for a node between runs? Our agents run hourly. We are using open source PuppetDB 3.0.2. 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/6d0194fd-6fe9-4e2a-9cce-28ac487e8540%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB - High CPU Large number of KahaDB files and very little work going to postgresql
Hi Mike, glad to hear I'm not the only one with the headaches :) We are planning on upgrading everything across the board from puppet server, puppet agent and puppet db. At least now I can get back to planning that! Our catalog/resource duplication is zero after about 5 hours of running. I need to look at this as well but suspect each agent run has different data or catalog compile. I need to look into those more just like you do when time permits. Command queue has peeked at 5 max and command processing/sec is 1.93. Let me know if you have any questions. On Wednesday, June 28, 2017 at 12:25:57 PM UTC-4, Peter Krawetzky wrote: > > 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/1b82f569-81b0-4bbf-8f49-f2e94a799e21%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB low catalog-duplication rate Puppet DB 4.3.0
So I went to run the curl command listed below and it came back with nothing. So I used pgadmin to look at the catalogs table and it's completely empty. The system has been running for almost 24 hours after dropping/creating the postgresql database. Any idea why the catalog table would be empty? On Wednesday, June 28, 2017 at 2:11:17 PM UTC-4, 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d2aad3a9-40d2-4d79-bb46-32e2ffe357e5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet Minor Upgrade
I need a clarification on a comment in the puppet upgrade doci. Does this mean (last sentence below) I can upgrade the puppetdb servers before the puppetservers and puppet agent? It's the "nodes" comment that has me confused. I take that as it can go before anything. A minor upgrade is an upgrade from one Puppet 4 release to another. The order in which you upgrade packages is important. Always upgrade puppetserver on your masters *before* you upgrade agents. *You can upgrade PuppetDB before or after you upgrade other nodes.* -- 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/074f9f65-d10b-4ab6-b544-07717b7b438e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Compare node fact runs
Do you have a link to those posts Mike? On Thursday, July 6, 2017 at 12:54:37 PM UTC-4, Peter Krawetzky wrote: > > I'm seeing a lot of replace facts in the puppetdb server log. I googled > but can't find anything solid. > > Is there a way to compare facts for a node between runs? Our agents run > hourly. We are using open source PuppetDB 3.0.2. > > 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/ef0caed9-04f1-4977-afe9-deee1fc31db7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: PuppetDB low catalog-duplication rate Puppet DB 4.3.0
Yes I am on V4 and the query just didn't return any results - no errors so I assume I am using the correct curl command. Thanks On Wednesday, June 28, 2017 at 2:11:17 PM UTC-4, 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d3b49873-5665-4286-bba2-b69ae304ae8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] PuppetDB Curl Queries
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.
[Puppet Users] Re: PuppetDB Curl Queries
Isn't that for the PE version? we are using open source. On Tuesday, July 11, 2017 at 11:48:35 AM UTC-4, 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/a8be2d5d-f224-46b5-b72d-97338b24d44e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Upgraded puppet server and hiera is not working
I upgraded the puppet server from 2.1.1-1 to 2.7.2-1 and at the same time
the puppet agent was upgraded from 1.2.2-1 to 1.10.4-1.
I read several different posts on this forum and others but I can't seem to
get hiera 5 to work properly. I tried a couple of different hiera.yaml
config files yet nothing seems to work correctly. I've tried to use the
old hiera.yaml version and getting the expected depricated warning. The
Puppet doci on V5 and converting is not the greatest.
Our hiera config uses both json files and couchdb. Everytime I run puppet
lookup I get:
[root@xlabsvcpup4 code]# puppet lookup pup_url
Warning: /etc/puppetlabs/code/hiera.yaml: Use of 'hiera.yaml' version 3 is
deprecated. It should be converted to version 5
(in /etc/puppetlabs/code/hiera.yaml)
Warning: Undefined variable '::my_role';
(file & line not available)
Error: Could not run: HTTP request path is empty
Current hiera.yaml file:
[root@xlabsvcpup4 code]# cat hiera.yaml
---
:backends:
- http
- json
- yaml
:hierarchy:
- "%{::clientcert}"
- "%{::environment}/%{::clientcert}"
- "%{::environment}/%{::my_role}"
- "%{::environment}/common"
- "%{::my_role}"
- common
:json:
:datadir: /u01/hieradata/
:yaml:
:datadir: /u01/hieradata/
:http:
:host: couchdb.com
:port: 5984
:output: json
:failure: graceful
:use_auth: true
:auth_user: 'userid'
:auth_pass: 'password'
:paths:
- /hieradb/%{::clientcert}
- /%{::environment}/%{::my_role}
- /%{::environment}/common
- /hieradb/%{::my_role}
- /hieradb/common
I tried to use this version 5 config file:
---
version: 5
defaults:
datadir: "/u01/hieradata"
data_hash: json_data
hierarchy:
- name: "json files"
paths:
- "%{::clientcert}.json"
- "%{::environment}/%{::clientcert}.json"
- "%{::environment}/%{::my_role}.json"
- "%{::environment}/common.json"
- "%{::my_role}.json"
- common.json
- name: "Couchdb"
options:
connections:
hiera3_backend: hiera-http
host: couchdb.com
output: json
failure: graceful
use_auth: true
auth_user: 'userid'
auth_pass: 'password'
paths:
- /hieradb/%{::clientcert}
- /%{::environment}/%{::my_role}
- /%{::environment}/common
- /hieradb/%{::my_role}
- /hieradb/common
When I use the V5 config i get:
Warning: Undefined variable '::my_role';
(file & line not available)
Error: Could not run: 'json_data' one of 'path', 'paths' 'glob', 'globs' or
'mapped_paths' must be declared in hiera.yaml when using t
--
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/c18c3f70-d65b-4de9-96b1-d56602b782e3%40googlegroups.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
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.
[Puppet Users] puppetserver-acces.log
We had an odd situation happen earlier this morning. Puppet server version 2.1.1 on RHEL7. I have 4 puppet servers behind a load balancing F5 server. One of our puppet servers puppetserver-access.log grew (over 2TB's) to the point that it almost filled /var which for a server is not good. I don't see anything different in this log compared to the other 3 servers. Does anyone know what would cause this log to grow? Is there a way to turn it off as I don't see that in the documentation? I watched the F5 balancing and it was distributing all workload across all 4 servers correctly. I also restarted the puppetserver service on this on server to see if maybe something was stuck. Because there is so much data, it's extremely hard to see any patterns. Thanks in advance for any assistance. -- 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/67355598-c726-4d24-be0a-bb55166f3576%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: puppetserver-acces.log
Since I don't have a setting in the file, it defaults to info. Unless there is a bug. On Monday, October 2, 2017 at 10:24:19 AM UTC-4, Peter Krawetzky wrote: > > We had an odd situation happen earlier this morning. Puppet server > version 2.1.1 on RHEL7. > > I have 4 puppet servers behind a load balancing F5 server. One of our > puppet servers puppetserver-access.log grew (over 2TB's) to the point that > it almost filled /var which for a server is not good. I don't see anything > different in this log compared to the other 3 servers. Does anyone know > what would cause this log to grow? Is there a way to turn it off as I > don't see that in the documentation? > > I watched the F5 balancing and it was distributing all workload across all > 4 servers correctly. I also restarted the puppetserver service on this on > server to see if maybe something was stuck. Because there is so much data, > it's extremely hard to see any patterns. > > Thanks in advance for any assistance. > -- 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/e8fd7154-9f69-4234-8376-9a6f9c056640%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: puppetserver-acces.log
So I recycled the puppetserver service and it now appears the log is back to normal size over the course of time. I'm guessing something happened to cause puppetserver to dump more than it should have. On Monday, October 2, 2017 at 10:24:19 AM UTC-4, Peter Krawetzky wrote: > > We had an odd situation happen earlier this morning. Puppet server > version 2.1.1 on RHEL7. > > I have 4 puppet servers behind a load balancing F5 server. One of our > puppet servers puppetserver-access.log grew (over 2TB's) to the point that > it almost filled /var which for a server is not good. I don't see anything > different in this log compared to the other 3 servers. Does anyone know > what would cause this log to grow? Is there a way to turn it off as I > don't see that in the documentation? > > I watched the F5 balancing and it was distributing all workload across all > 4 servers correctly. I also restarted the puppetserver service on this on > server to see if maybe something was stuck. Because there is so much data, > it's extremely hard to see any patterns. > > Thanks in advance for any assistance. > -- 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/ae6fe59e-6aad-4919-9c02-4bcdbb619da4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Fresh install of Opensource puppetdb on RHEL 7.3 using Postgresql 9.6 pg_log errors
Just installed a new copy of postgresql 9.6 on a server that was running 9.4. Upgraded puppetdb to 5.2.4 on the same server. After startup the pg_log file has been throwing the following error: ERROR: canceling autovacuum task I suspect puppetdb is holding a lock but not sure where. It also doesn't identify what table it's trying to autovacuum. Anyone else experiencing this issue? I'm worried that without autovacuum the database is not going to get cleaned up. -- 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/4c865daa-2912-4b70-8ce8-9e1fa24a5fb2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Latest version of lookup_http not in rubygems.org
I'm trying to an SSL connection from puppetserver to a couchdb no-sql database for hiera lookup data. I have both hiera-http and lookup_http installed however the version of lookup_http.rb file that gets installed from running the puppetserver gem install command is 1.0.3. The version I want to install is 1.4.0 https://github.com/crayfishx/lookup_http Is there any way I can get the 1.4.0 version installed on my puppetserver? SSL was supported in 1.2.0 so I figured I would just install the latest. -- 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/70ad68b8-5fe6-42ed-a15d-85433b9e2992%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Latest version of lookup_http not in rubygems.org
Yeah it looks like I did get this in reverse but it doesn't explain why an SSL connection is not working to couchdb. On Tuesday, February 19, 2019 at 4:23:26 PM UTC-5, Peter Krawetzky wrote: > > I'm trying to an SSL connection from puppetserver to a couchdb no-sql > database for hiera lookup data. I have both hiera-http and lookup_http > installed however the version of lookup_http.rb file that gets installed > from running the puppetserver gem install command is 1.0.3. The version I > want to install is 1.4.0 https://github.com/crayfishx/lookup_http > > Is there any way I can get the 1.4.0 version installed on my > puppetserver? SSL was supported in 1.2.0 so I figured I would just install > the latest. > -- 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/3823bae5-2d21-419f-83a0-c3403d715c35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Puppet Log Directory Permissions
I want to be able to ingest the puppet servers logs into splunk but the owner of the directory is puppet:puppet and the permissions are /var/log/puppetlabs/puppet rwxr-x---. Since other has no access, the splunk service will not be able to read the log files. Can I just change the permissions to rwxr-xr-x without any adverse affects to the puppetserver process? Is there a way to do this in a puppetserver config file like logback.xml? -- 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/0c69b316-a7ff-4417-84db-eb46f92882a4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Puppet Log Directory Permissions
Interesting, thanks! On Tuesday, June 4, 2019 at 1:59:07 PM UTC-4, Peter Krawetzky wrote: > > I want to be able to ingest the puppet servers logs into splunk but the > owner of the directory is puppet:puppet and the permissions are > /var/log/puppetlabs/puppet rwxr-x---. Since other has no access, the > splunk service will not be able to read the log files. Can I just change > the permissions to rwxr-xr-x without any adverse affects to the > puppetserver process? Is there a way to do this in a puppetserver config > file like logback.xml? > -- 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/dbd9bd2a-4219-4af4-99ad-3914db993002%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] PuppetDB Using Puppetlabs Postgresql Module on Linux
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.
[Puppet Users] Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'quick_check'
I've reviewed sever 500 error posts in here but the answers seem to differ
based on the situation.
One of our developers modified code to include a parameter available in
httpfile 0.1.9 called quick_check.
We have two installation of puppetserver one in lab domain and one in
production domain. Neither talk to the other domain. It is completely
isolated to the nodes in each domain.
What's odd is lab works but when they deploy the code to production, it
doesn't work and received the 500 error below. I've compared everything
between puppetserver versions, puppet versions, httpfile module versions,
etc and nothing is obvious.
This httpfile module is not installed using puppet module install but is
placed in the same location as other modules created by the developers.
I've verified the code was deployed correctly to each of the 4 production
puppetservers (we use a load balancer to distribute the work) into the
environment defined at the node (dev).
Code:
### DOWNLOAD FROM REPO
define oracle::remote_file($remote_location=undef, $mode='0644', $owner='
root', $group='root'){
httpfile { "${title}":
ensure => present,
path => "${title}",
source => "$remote_location",
quick_check => true,
# hash => 'hex form SHA2 hash OR an URL to the .sha file with that hash'
}
file{$title:
owner => $owner,
group => $group,
mode => $mode,
require => Httpfile["${title}"],
}
}
Error:
2020-07-15T08:35:15.325976-04:00 myserver puppet-agent[24036]: Could not
retrieve catalog from remote server: Error 500 on SERVER: Server Error: no
parameter named 'quick_check' (file:
/u01/puppet/dev/modules/oracle/manifests/remote_file.pp, line: 6) on
Httpfile[/var/opt/BESClient/LMT/oracle/options_packs_usage_statistics.sql]
(file: /u01/puppet/dev/modules/oracle/manifests/remote_file.pp, line: 6) on
node myserver.mydomain.com
Any ideas what might be causing this? Is there some cache not being
refreshed on the pupperserver?
--
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/886fd9da-c841-4d8b-80f3-d23bc2429e68o%40googlegroups.com.
Re: [Puppet Users] Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'quick_check'
Does this work for Open Source or PE? My installation is using Open Source.
Also can you provide an example of the actual curl command? I can't seem
to get the exact syntax down for it to work.
Thanks for the advice.
On Thursday, July 16, 2020 at 7:55:51 PM UTC-4, Justin Stoller wrote:
>
> It maybe because of a long environment timeout:
> https://puppet.com/docs/puppet/5.5/environments_creating.html#task-3930
> In PE this is set to unlimited by default when using code management. The
> code manager will then manually evict the cache after a code deployment to
> ensure that new code is viewable and old code is cached for as long as
> possible. If you are caching code with a long environment timeout, but not
> using code management you can also evict the cache by using the
> environment-cache endpoint:
>
> https://puppet.com/docs/puppetserver/latest/admin-api/v1/environment-cache.html
>
> HTH,
> Justin
>
> On Thu, Jul 16, 2020 at 10:52 AM Peter Krawetzky > wrote:
>
>> I've reviewed sever 500 error posts in here but the answers seem to
>> differ based on the situation.
>>
>>
>> One of our developers modified code to include a parameter available in
>> httpfile 0.1.9 called quick_check.
>>
>> We have two installation of puppetserver one in lab domain and one in
>> production domain. Neither talk to the other domain. It is completely
>> isolated to the nodes in each domain.
>>
>> What's odd is lab works but when they deploy the code to production, it
>> doesn't work and received the 500 error below. I've compared everything
>> between puppetserver versions, puppet versions, httpfile module versions,
>> etc and nothing is obvious.
>>
>>
>> This httpfile module is not installed using puppet module install but is
>> placed in the same location as other modules created by the developers.
>>
>> I've verified the code was deployed correctly to each of the 4 production
>> puppetservers (we use a load balancer to distribute the work) into the
>> environment defined at the node (dev).
>>
>>
>> Code:
>> ### DOWNLOAD FROM REPO
>> define oracle::remote_file($remote_location=undef, $mode='0644', $owner='
>> root', $group='root'){
>>
>> httpfile { "${title}":
>> ensure => present,
>> path => "${title}",
>> source => "$remote_location",
>> quick_check => true,
>> # hash => 'hex form SHA2 hash OR an URL to the .sha file with that hash'
>> }
>> file{$title:
>> owner => $owner,
>> group => $group,
>> mode => $mode,
>> require => Httpfile["${title}"],
>> }
>> }
>>
>>
>> Error:
>>
>> 2020-07-15T08:35:15.325976-04:00 myserver puppet-agent[24036]: Could not
>> retrieve catalog from remote server: Error 500 on SERVER: Server Error: no
>> parameter named 'quick_check' (file:
>> /u01/puppet/dev/modules/oracle/manifests/remote_file.pp, line: 6) on
>> Httpfile[/var/opt/BESClient/LMT/oracle/options_packs_usage_statistics.sql]
>> (file: /u01/puppet/dev/modules/oracle/manifests/remote_file.pp, line: 6) on
>> node myserver.mydomain.com
>>
>>
>> Any ideas what might be causing this? Is there some cache not being
>> refreshed on the pupperserver?
>>
>> --
>> 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/886fd9da-c841-4d8b-80f3-d23bc2429e68o%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/puppet-users/886fd9da-c841-4d8b-80f3-d23bc2429e68o%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/506125c9-66df-4f67-84fc-1a10b1b137dbo%40googlegroups.com.
Re: [Puppet Users] Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: no parameter named 'quick_check'
Ok I figured out the curl command but I get this error: [root@mypuppetserver private_keys]# curl -v --header "Content-Type: application/json" --cert /etc/puppetlabs/puppet/ssl/certs/mypuppetserver.mydomain.com.pem --key /etc/puppetlabs/puppet/ssl/private_keys/mypuppetserver.mydomain.com.pem --cacert /etc/puppetlabs/puppet/ssl/ca/ca_crt.pem -X DELETE https://mypuppetserver.mydomain.com:8140/puppet-admin-api/v1/environment-cache * About to connect() to mypuppetserver.mydomain.com port 8140 (#0) * Trying xx.xx.xxx.xx... * Connected to mypuppetserver.mydomain.com (xx.xx.xxx.xx) port 8140 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * CAfile: /etc/puppetlabs/puppet/ssl/ca/ca_crt.pem CApath: none * NSS: client certificate from file * subject: CN=mypuppetserver.mydomain.com * start date: Aug 14 15:32:34 2018 GMT * expire date: Aug 14 15:32:34 2023 GMT * common name: mypuppetserver.mydomain.com * issuer: CN=Puppet CA: mypuppetcaserver.mydomain.com * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA * Server certificate: * subject: CN=mypuppetserver.mydomain.com * start date: Aug 14 15:32:34 2018 GMT * expire date: Aug 14 15:32:34 2023 GMT * common name: mypuppetserver.mydomain.com * issuer: CN=Puppet CA: mypuppetcaserver.mydomain.com > DELETE /puppet-admin-api/v1/environment-cache HTTP/1.1 > User-Agent: curl/7.29.0 > Host: mypuppetserver.mydomain.com:8140 > Accept: */* > Content-Type: application/json > < HTTP/1.1 403 Forbidden < Date: Fri, 17 Jul 2020 13:41:37 GMT < Content-Length: 115 < Server: Jetty(9.4.z-SNAPSHOT) < * Connection #0 to host mypuppetserver.mydomain.com left intact Forbidden request: /puppet-admin-api/v1/environment-cache (method :delete). Please see the server logs for details.[root@mypuppetserver private_keys]# *puppetserver.log entries*: 2020-07-17 09:07:45,577 ERROR [qtp2067827614-66] [p.t.a.rules] Forbidden request: 0:0:0:0:0:0:0:1 access to /puppet-admin-api/v1/environment-cache (method :delete) (authenticated: false) denied by rule 'puppetlabs deny all'. 2020-07-17 09:07:45,585 ERROR [qtp2067827614-65] [p.t.a.rules] Forbidden request: 0:0:0:0:0:0:0:1 access to /puppet-admin-api/v1/environment-cache (method :delete) (authenticated: false) denied by rule 'puppetlabs deny all'. 2020-07-17 09:12:02,951 ERROR [qtp2067827614-63] [p.t.a.rules] Forbidden request: xx.xx.xxx.xx access to /puppet-admin-api/v1/environment-cache (method :delete) (authenticated: false) denied by rule 'puppetlabs deny all'. 2020-07-17 09:17:29,677 ERROR [qtp2067827614-61] [p.t.a.rules] Forbidden request: xx.xx.xxx.xx access to /puppet-admin-api/v1/environment-cache (method :delete) (authenticated: false) denied by rule 'puppetlabs deny all'. 2020-07-17 09:41:37,401 ERROR [qtp2067827614-63] [p.t.a.rules] Forbidden request: mypuppetserver.mydomain.com(xx.xx.xxx.xx) access to /puppet-admin-api/v1/environment-cache (method :delete) (authenticated: true) denied by rule 'puppetlabs deny all'. -- 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/173aa581-ddde-4e2a-aa46-b9666f93e844o%40googlegroups.com.
