Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox updated an issue PuppetDB / PDB-4625 puppetdb ssl connection to postgresql broken Change By: Paladox Priority: Critical Major Upgrading from 6.7 to 6.8 caused ssl connection issues with postgresql, from what i could see in the logs it said: puppetdb: 2020-01-16T01:59:09.295Z ERROR [p.p.c.services] Will retry database connection after temporary failure: java.sql.SQLTransientConnectionException: PDBMigrationsPool - Connection is not available, request timed out after 3000ms. postgresql logs show : " 2020-01-16 01:56:41 GMT LOG: could not accept SSL connection: Success " Downgrading back to 6.7 worked. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs"
Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox updated an issue PuppetDB / PDB-4625 puppetdb ssl connection to postgresql broken Change By: Paladox Affects Version/s: PDB 6.9.0 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.342311.1579141305000.31306.1582126741110%40Atlassian.JIRA.
Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox updated an issue PuppetDB / PDB-4625 puppetdb ssl connection to postgresql broken Change By: Paladox Affects Version/s: PDB 6.8.1 Environment: Debian Stretch (9) and Debian Buster ( 10 ) Master OS: Other Agent OS: Other Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit
Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox commented on PDB-4625 Re: puppetdb ssl connection to postgresql broken Bump Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.342311.1579141305000.19617.1581217320211%40Atlassian.JIRA.
Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox commented on PDB-4625 Re: puppetdb ssl connection to postgresql broken Could this https://github.com/puppetlabs/puppetdb/commit/2a43a1057ab8dcd8354d06f3d221313c50669c12 have broken it? Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.342311.1579141305000.26377.1579141800135%40Atlassian.JIRA.
Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox commented on PDB-4625 Re: puppetdb ssl connection to postgresql broken The postgresql version is 9.6+181+deb9u3 running on debian 9 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.342311.1579141305000.26374.1579141500132%40Atlassian.JIRA.
Jira (PDB-4625) puppetdb ssl connection to postgresql broken
Title: Message Title Paladox created an issue PuppetDB / PDB-4625 puppetdb ssl connection to postgresql broken Issue Type: Bug Affects Versions: PDB 6.8.0 Assignee: Unassigned Components: PuppetDB Created: 2020/01/15 6:21 PM Environment: Debian 10 Priority: Critical Reporter: Paladox Upgrading from 6.7 to 6.8 caused ssl connection issues with postgresql, from what i could see in the logs it said: puppetdb: 2020-01-16T01:59:09.295Z ERROR [p.p.c.services] Will retry database connection after temporary failure: java.sql.SQLTransientConnectionException: PDBMigrationsPool - Connection is not available, request timed out after 3000ms. postgresql: 2020-01-16 01:56:41 GMT LOG: could not accept SSL connection: Success Downgrading back to 6.7 worked. Add Comment
Jira (PUP-9396) Puppet agent is not correctly writing events: failed:
Title: Message Title Paladox created an issue Puppet / PUP-9396 Puppet agent is not correctly writing events: failed: Issue Type: Bug Affects Versions: PUP 6.0.0 Assignee: Unassigned Created: 2019/01/03 8:00 PM Environment: Debian 9 Priority: Critical Reporter: Paladox Hi, i recently upgraded from puppet 4.8 to 6.1 on debian 9. Since then i noticed if i make error like: Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: The parameter $name redefines a built in parameter in the 'define' _expression_ (file: /etc/puppetlabs/puppet/environments/production/modules/monitoring/manifests/wiki.pp, line: 3, column: 5) on node misc1.miraheze.org the servers las run summery file ( /opt/puppetlabs/server/data/puppetserver/state/last_run_summary.yaml ) only shows events: failure: 0 success: 0 total: 0 even though the catalog failed. Under puppet 4.8 this worked but under 6.1 it seems to have different behaviour. I made a error a few days ago without realising my mistake until i tried running puppet.
Jira (FACT-1901) $processor count under openvz reporting incorrectly
Title: Message Title Paladox updated an issue Facter / FACT-1901 $processor count under openvz reporting incorrectly Change By: Paladox Labels: linux virtualization Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1901) $processor count under openvz reporting incorrectly
Title: Message Title Paladox updated an issue Facter / FACT-1901 $processor count under openvz reporting incorrectly Change By: Paladox Labels: virtualization Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1901) $processor count under openvz reporting incorrectly
Title: Message Title
Paladox updated an issue
Facter / FACT-1901
$processor count under openvz reporting incorrectly
Change By:
Paladox
Hi, im trying to upgrade from puppet 4.8 (from the official debian repo) to puppet 6.1.0 from puppet labs. I discovered that facter v3 is reporting incorrect information for a virtual host under 6 the processor coun . 1.0 compared to 4.8. Under 6.1.0 i see this (facter 3): physicalprocessorcount => 40processor0 => Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHzprocessorcount => 40processors => { { count => 40, isa => "unknown", models => [ "Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz" ], physicalcount => 40 } under puppet 4.8 i see this (facter 2) physicalprocessorcount => 0processor0 => Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHzprocessorcount => 1processors => \ {"models"=>["Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz"], "count"=>1, "physicalcount"=>0} facter 2 is showing the correct information compared to facter 3. It seems facter 3 is showing the physical hosts processors count. We rely on this information to determine how much childs start under php-fpm. (this also runs openvz) Im not sure if i reported this is the correct place or what additional information is needed.
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (FACT-1901) $processor count under openvz reporting incorrectly
Title: Message Title Paladox updated an issue Facter / FACT-1901 $processor count under openvz reporting incorrectly Change By: Paladox Summary: Facter $processor count under openvz reporting incorrect information on a virtual host incorrectly Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1453) $ipaddress on openvz container returning 127.0.0.2
Title: Message Title Paladox commented on FACT-1453 Re: $ipaddress on openvz container returning 127.0.0.2 Hi, i get this too, i worked around this by doing https://github.com/miraheze/puppet/blob/master/modules/vmlib/lib/facter/virtual_ip_address.rb Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1901) Facter reporting incorrect information on a virtual host
Title: Message Title Paladox commented on FACT-1901 Re: Facter reporting incorrect information on a virtual host Happens with ip to, so i've created 2 temporarily custom facts (one that uses the etc module and the other using socket). Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-1901) Facter reporting incorrect information on a virtual host
Title: Message Title Paladox commented on FACT-1901 Re: Facter reporting incorrect information on a virtual host i think this https://github.com/puppetlabs/facter/blob/2aa2d1cd6487f73fb8e311cf027dcf30c2166e28/lib/src/facts/linux/processor_resolver.cc#L76 may be the roble as that shows 39 for me compared to /proc/cpuinfo (which shows) cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 79 model name : Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz stepping : 1 microcode : 184549409 cpu MHz : 2400.205 cache size : 25600 KB physical id : 0 siblings : 20 core id : 0 cpu cores : 10 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 20 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good eagerfpu xtopology nonstop_tsc aperfmperf cpuid_faulting pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch arat epb pln pts dtherm invpcid_single pti retpoline tpr_shadow vnmi flexpriority ept vpid fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm rdseed adx xsaveopt cqm_llc cqm_occup_llc bogomips : 4800.41 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group
Jira (FACT-1901) Facter reporting incorrect information on a virtual host
Title: Message Title
Paladox created an issue
Facter / FACT-1901
Facter reporting incorrect information on a virtual host
Issue Type:
Bug
Affects Versions:
FACT 3.12.2
Assignee:
Unassigned
Created:
2018/12/22 4:51 PM
Priority:
Major
Reporter:
Paladox
Hi, im trying to upgrade from puppet 4.8 (from the official debian repo) to puppet 6.1.0 from puppet labs. I discovered that facter is reporting incorrect information for a virtual host under 6.1.0 compared to 4.8. Under 6.1.0 i see this (facter 3): physicalprocessorcount => 40 processor0 => Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz processorcount => 40 processors => { count => 40, isa => "unknown", models => [ "Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz" ], physicalcount => 40 } under puppet 4.8 i see this (facter 2) physicalprocessorcount => 0 processor0 => Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz processorcount => 1 processors => {"models"=>["Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz"], "count"=>1, "physicalcount"=>0} facter 2 is showing the correct information compared to facter 3. It seems facter 3 is showing the physical hosts processors count. We rely on this information to determine how much childs start under php-fpm. (this also runs openvz) Im not sure if i reported this is the correct place or what additional information is needed.
