[mrtg] Call for Discussion: how to design a interface filter function for cfgmaker.

[Jakob Ilves]

Hello!

I've been working on yet another feature for MRTG cfgmaker, a function
called --if-filter=expression where "expression" is something which is
used to decide which interfaces on a router to include into the config
file and which to exclude.

The solution I'm working on right now is to let "expression" be Perl
code which is evaluated once per interface.  If the code returns "true",
the interface will be included in the config, otherwise the interface is
excluded.  To facilitate the writing of the expression, some variables
are supposed to be predefined.  For instance, the variable $if_is_lan is
true for all interface types which are LAN interfaces etc.  As the
string is a Perl expression, comparision operators, parenthesis, boolean
operators, regexp pattern matching etc are available for the user.  Of
course, the user might access a lot of the cfgmaker programs variables,
but only a certain number of variables are "supported" (and thus
supposed to be backward compatible for future cfgmaker releases).

Assume that I want include all interfaces which are admin up (regardless
of their oper status) but I don't want any dial-up interfaces (which
will exclude the ISDN as well in my design).  The variable $if_admin is
true if the interface is administrative up.  The variable
$default_iftype is assumed to be true only if the type normally would be
accepted by cfgmaker (regardless of the interfaces oper and admin
state).

To do the filtering I mention above (ignore the oper state, only
consider admin state, reject all dial up and include all DS3
controllers) the following filter would be good:

--if-filter '($default_iftype and (not $if_is_dialup) and $admin)'

The good thing is that this approach is powerful.  The user might mix
and match tests/variables to get a behavior of cfgmaker which fits
his/her needs.  My intent is to make this filter versatile enough to
allow for filtering interfaces on what OSPF area they belong to (for
example to get a collection with OSPF backbone interfaces) and to filter
interfaces on wether or not the CDP (Cisco Discovery Protocol) says the
interface is connected to another Cisco box or not (to get switch
uplinks and filter away host/user ports).

The bad thing is that it is easy to make mistakes which show up with
very unclear error messages.  As variables in Perl are referenced by
prepending their names with a $ sign there is a problem, as the $ sign
also is an active character in most shells and thus must be properly
escaped in order to be noticed by cfgmaker.

Me and Tobias has discussed a number of alternatives for this and I
would like to hear your opinion as well on these alternative:

1.) Leave the Perl code alone, don't preprocess it.  Advantage: it is
easy to handle for those who are familiar with Perl and it requires no
preprocessing of the provided Perl code and thus there is no need to
cleverly design a preprocessor.  Disadvangate:  if quoting of the code
is not done properly the shell will interprete the string and it's
special characters ($, :, @ etc) according to shell syntax and thus it
will mangle the code increasing the "support load" on the MRTG list.
Also, Perl code might be clumsy, even if it's powerful.

Example as per above: --if-filter '($default_iftype and (not
$if_is_dialup) and $admin)'

2.) Preprocess the code to allow the user to use an EASY syntax in the
expression.  Example: allow the varables to be referred to as
"{variablename}" instead of "${variablename} or "$variablename" but
otherwise leave the code untouched.  To let more advanced users include
"normal" curly braces, esape them with backslash like this \{ or \}.
The escape of them is mainly necessary I suppose if they are supposed to
appear in regular expressions.  Advantages: we can refer to variables
without dollar signs and with perhaps less clumsy code.  Disadvantages:
it's almost Perl but not really Perl, making it trickier for those who
know perl...

Example as per above: --if-filter '({default_iftype} and (not
{if_is_dialup}) and {admin})'

3.) Preprocess the code to ensure the user a ROBUST syntax in the
expression.  This means use something which is extremely non-Perl and
non-Shell (perhaps @varablename@ being transformed into ${variablename}
or whatever).  The good thing is that if the user happens to not quote
this, the shell leaves the strings alone and then it is fed into Perl
which hopefully protests loudly.  The bad thing is that the design of
this is difficult (what characters are left which aren't special for the
shell and for Perl?).

Example as per above: --if-filter '(@default_iftype@ and (not
@if_is_dialup@) and @admin@)'

Worth noting is that I am planning to implement "templates", which will
simply files with snippets of Perl code which is evaluated to generate
the target code for each target, for those who want to have better
control of what cfgmaker outputs for each target, without needing to
hack the cfgmaker script itself.  Those template files will have normal
Perl code (not being fed into any preprocessor) with a certain number of
predifined variables such as interface speed, hostname, host description
etc.  Note that the templates are not only focused on interfaces but
also on hosts themselves, making it easy to setup your own kind of CPU
monitoring or ping response time monitoring.

Having two different treatments of the Perl for two different features
might be confusing...

Frankly, I don't know.  I just feel that there is a number of
inconvenient solutions to choose betwee and that's I ask you what you
think...  As they say in English: "pick your poison".

Best regards

/IlvJa

--
                (Jakob Ilves) <jakob.ilves at oracle.com>
             {Oracle Global IT, Network Management Group}
[Office as well as mobile phone: +46/8/477 3666 | Fax: +46/8/477 3572]




-- Attached file removed by Listar and put at URL below --
-- Type: text/x-vcard
-- Desc: Card for Jakob Ilves
-- Size: 444 bytes
-- URL : http://www.ee.ethz.ch/~slist/pantomime/33-jakob.ilves.vcf


--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi