Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Splitting innreport.conf into 2 files? (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sat, 25 Sep 2021 12:11:02 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Splitting innreport.conf into 2 files?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> innreport.conf consists of about 50 lines of general parameters and then
> of about 2400 lines for configuring what to display in the report. I
> believe most users do not need to configure the display. Having it in
> innreport.conf does not permit fixing possible bugs or improving it
> during an INN update.
I think this is an excellent idea.
> Couldn't <pathetc>/innreport.conf be split into:
> - <pathetc>/innreport.conf for general parameters only
> - <path???>/innreport-display.conf (or any better name) for the rest
<pathlib>/innreport-display.conf would put it alongside innreport_inn.pm,
which feels correct to me.
The entire innreport implementation is unfortunately very difficult to
maintain since the separation of concerns between code and data is
ill-defined and there's no way to overlay or select specific changes to
the display layer. (It's also written in a fairly old dialect of Perl.)
I tried to rewrite it once and ended up with a different system that had
different problems, which was never released outside of Stanford.
One of the difficulties with the current implementation is that the
configuration file is essentially written in a DSL that's a subset of
Perl, so a backward-compatible replacement requires writing a parser and
execution layer for that DSL. (See EvalExpr in the innreport script.)
Ideally it would get a complete redesign, but I am doubtful anyone will
have time and inclination to do that work. The modern way of achieving
the same result is to feed all the relevant data into Prometheus or some
other generic monitoring system and then use Grafana or similar software
to generate reports and graphs. (Also quite a lot of work!)
> Of course, a new parameter should be added in innreport.conf to specify
> an alternate display file (display_conf_file "" related to <pathetc>
> this time).
I think this is the right way to handle local modifications.
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 133, Issue 15
********************************************
