[rrd-users] Splitting database and graphing functionality

Sven-Göran Bergh svengbergh-rrdtool at yahoo.com
Thu May 31 22:41:16 CEST 2012


Hi,



>Från: "Duncan.Innes at virginmoney.com" <Duncan.Innes at virginmoney.com>
>Till: rrd-users at lists.oetiker.ch 
>Skickat: torsdag, 31 maj 2012 11:11
>Ämne: [rrd-users] Splitting database and graphing functionality
> 
>
>Hi, 
>
>I've been using rrdtool for a number
of years now, but have recently had it come under the spotlight from our
IT Security team. 
>
>As a bank, we have a strong lean towards
reducing the number of installed packages to reduce the possible attack
surface for any potential issues. 
>
>To this end, I have been asked why we
need to be installing a bunch of graphics, font and rendering packages
on all our servers when all we're looking to do is record data in RRD's
most of the time. 
>
>Is it possible/feasible to split the
database and rendering functions of rrdtool into separate packages?  For
example a base rrdtool package containing just RRD management functionality
and a modular rrdtool-graph containing the rendering & graphing functions.
 This would allow security conscious users to deploy the base rrdtool
package to record data across an estate of machines and then install the
extra rrdtool-graph package on a central machine to handle the graph rendering. 
>
>Does this sound realistic?  Achievable?
Worthwhile? 
>
>Thanks 
>
>Duncan

Interesting! we have the same problem, but from an embedded POV.
The system only do rrdtool create/update. No graphing, no CGI,
etc. so the additional bloat is a concern for us. It goes without
saying that Perl is a no-no as well.


There is a compilation target in the source called rrdupdate
without any external dependencies that looks promising.
However, we still need a replacement for "rrdtool create".

Such a replacement without external dependencies together with
rrdupdate  would be the solution for both of us.


Hopefully the list wizards might be able to spread some light
on this.

Brgds
/Sven




More information about the rrd-users mailing list