patch is missing additional tests but this is not an issue

bug 919493 dose not affect jessie

jessie

DebDiff Report

diff -Nru tar-1.27.1/debian/changelog tar-1.27.1/debian/changelog
-- tar-1.27.1/debian/changelog  2016-10-30 06:48:55.000000000 +0000
++ tar-1.27.1/debian/changelog  2018-12-31 09:29:20.000000000 +0000
@ -1,3 +1,11 @@
tar (1.27.1-2+deb8u2) jessie-security; urgency=high
+
  * CVE-2018-20482: Fix a potential denial of service vulnerability where
    --sparse can loop endlessly if the file shrinks whilst it is being read.
    (Closes: #917377)
+
 -- Chris Lamb <lamby@debian.org>  Mon, 31 Dec 2018 09:26:14 +0000
+
tar (1.27.1-2+deb8u1) jessie-security; urgency=high

rasdaemon is now part of the buster policy

rasdaemon writes data to a sqlit3 file located in /var/lib/rasdaemon/ras-mc_event.db im not sure the format other then below but perhaps we could use that

discussion from meeting https://etherpad.wikimedia.org/p/SRE-Foundations-ulogd_discussion

discussion from meeting https://etherpad.wikimedia.org/p/SRE-Foundations-ulogd_discussion

Do we have a sense of volume of logs?

The data tracks metrics on all connections so may contain to much information for Prometheus. an example running on a test machine (jbond-puppet-client.puppet.eqiad.wmflabs) is below. I haven't looked in depth at the module however it can be configured to report on less information. That said Im wondering if this data is best placed in Prometheus or in logstashd. If we use Prometheus would it be better to push this date with via the gateway as there is a definite start and duration key

I have created a simple module for configuereing ulogd2 avalible in https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/486513/. The questions is what do we want to log and how do we want to log it. With the default configuration the module will produce the following:

https://bugzilla.redhat.com/show_bug.cgi?id=1440710, however applying that fix just causes a different error

in fact, the patch mentioned in the commit above is enough to fix the rspec tests. the stack trace i posted is produced when puppet tries to parse its catalogue to be submitted to puppetdb and therefore not relevant to rspec tests

I have also been trying to get this working the following is also a useful data point https://bugzilla.redhat.com/show_bug.cgi?id=1440710, however applying that fix just causes a different error.

The new package has now been deployed please re-open if there are further issues