This file is indexed.

/usr/share/doc/lire/user-manual/ch03s04.html is in lire-doc 2:2.1.1-2.1.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Merging Reports</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Lire User's Manual"><link rel="up" href="ch03.html" title="Chapter 3. Running Lire"><link rel="prev" href="ch03s03.html" title="Generating A Report From A Log File"><link rel="next" href="ch03s05.html" title="Sending Anonymized Log Files To A Responder"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Merging Reports</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03s03.html">Prev</a> </td><th width="60%" align="center">Chapter 3. Running <span class="application">Lire</span></th><td width="20%" align="right"> <a accesskey="n" href="ch03s05.html">Next</a></td></tr></table><hr></div><div class="section" title="Merging Reports"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect:merging-reports"></a>Merging Reports</h2></div></div></div><p><span class="application">Lire</span> supports the merging of reports: one can
        combine two reports into one bigger report.  This can be used to
        generate e.g. a weekly report from 7 daily reports, or generate a
        site-wide report from reports about the behaviour of each server on a
        site.</p><p>We describe how to manually merge reports using the
          command line tools <span class="command"><strong>lr_xml2report</strong></span>, but the
          simplest way to use merging is through the DLF store
          interface which is described at <a class="xref" href="ch04.html" title="Chapter 4. Using DLF Stores">Chapter 4, <i>Using DLF Stores</i></a>.
        </p><p>We give an example.</p><div class="example"><a name="id381855"></a><p class="title"><b>Example 3.4. Merging Reports</b></p><div class="example-contents"><p>To process two BIND v9 logfiles, and merge the
            reports, one would run:</p><pre class="screen">
<code class="prompt">$ </code>lr_log2report --ouput xml bind9_query /var/log/named.2.gz \
    $XMLDIR/20020622.xml
<code class="prompt">$ </code>lr_log2report --output xml bind9_query /var/log/named.1.gz $XMLDIR/20020623.xml
<code class="prompt">$ </code> lr_xml2report --tempate dns_default \
    --merge $XMLDIR/20020623.xml  $XMLDIR/20020622.xml $ASCIIDIR/20020622-20020623.txt
          </pre><p>The <code class="option">--template</code> parameter is required
            for merging and specifies the report configuration
            template that should be used to merge the reports. You
            should probably use the same than the one that was used
            when you generate the reports. If you didn't specify one,
            (like in the above example) you should know that the
            default template is named
            <code class="constant"><em class="replaceable"><code>superservice</code></em>_default</code>.
            The list of available report configuration templates can
            be displayed by using the <strong class="userinput"><code>lr_xml2report --help report-templates</code></strong>.</p><p>The <code class="option">--merge</code> option is used to specify
            the other XML reports that should be merged before
            formatting the report. The <span class="command"><strong>lr_xml2mail</strong></span>
            command uses the same options for merging.
          </p></div></div><br class="example-break"><div class="section" title="Gotchas"><div class="titlepage"><div><div><h3 class="title"><a name="sect:merging-gotchas"></a>Gotchas</h3></div></div></div><p>The merging functionality is very powerful, and allows you to
          shoot yourself in the foot.  We document some pitfalls.</p><div class="section" title="Holes in your reporting period"><div class="titlepage"><div><div><h4 class="title"><a name="id381936"></a>Holes in your reporting period</h4></div></div></div><p>When merging XML report files xml.3 (2002-06-02 08:50:48 CEST
            - 2002-06-09 08:05:06 CEST) and xml.1 (2002-06-16 08:18:40 CEST -
            2002-06-21 22:13:09 CEST) , the generated report will gladly
            display "Reporting on period: 2002-06-02 08:50:48 CEST - 2002-06-21
            22:13:09 CEST": There is <span class="emphasis"><em>no</em></span> saveguard against
            forgetting in-between report files.</p></div><div class="section" title="Take care when changing report configuration template parameters"><div class="titlepage"><div><div><h4 class="title"><a name="id381952"></a>Take care when changing report configuration template
            parameters</h4></div></div></div><p>In some cases, changing the report configuration template
            just before merging might lead to bogus data in your report.</p><p>Consider this case: our firewall template contain a 
              subreport <span class="type">top-pkt-by-src</span> with the
              <em class="parameter"><code>ips_to_show</code></em> set to
              10, We process some firewall logs, and archive the XML
              reports.  
              If we change the <em class="parameter"><code>ips_to_show</code></em> to
              100 and merge the XML reports.  This could
            incorrectly omit some IPs!  You've got no guarantee the exact top
              100 IPs are shown.  This is due to the fact the XML reports do
              <span class="emphasis"><em>not</em></span> contain all information from the log:
              they're <span class="emphasis"><em>reports</em></span>, after all.
            </p><p>Due to these issues, the merging is implemented with
              some heuristics: we keep more data than what's requested
              by the user in the XML report, to be able to handle most
              after-the-fact merging requests. We've tested the
              algorithm with a pretty broad range of real-life log
              files, and found out generally, the merged reports do
              give a good reflection of what actually has happened on
              the network: the heuristic is pretty well choosen.
              However, if you really need guaranteed 100% accurate
              data, generate your report directly from the raw logs.
              If you just want a quick overview, the merging is more
              suitable. Just make sure you're not cranking the limit
              parameters up too high in this case.
            </p><p>See also the Report Generating chapter in the Lire
            
            Architecture part of the <em class="citetitle"><span class="application">Lire</span> Developer's Manual</em>.</p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch03s03.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch03.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ch03s05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Generating A Report From A Log File </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Sending Anonymized Log Files To A Responder</td></tr></table></div></body></html>