torrus/TODO

   1 Round Robin Database Framework
   2
   3 To do now:
   4
   5 -- index the parameters during compilation and add search function to UI
   6 -- Update User Guide
   7 -- Persistent maps in snmp collector
   8 -- Multithreading in collector
   9 -- Additive list parameters
  10 -- New security model (access control within a tree)
  11 -- New WebUI model
  12 -- take the CF for graphing from view definition
  13 -- implement new RPN functions: SORT, REV, TREND
  14 -- Display docsIfDownstreamChannelTable docsIfUpstreamChannelTable in
  15    DOCSIS chanel legends
  16 -- validate %Torrus::SQL::connections
  17 -- periodically refresh SNMP collector mappings
  18 -- Modular structure in Monitor, with pluggable actions
  19 -- in Monitor::run_event_exec, distinguish between monitor target and
  20    action target
  21 -- document selectors internals
  22 -- fix the bug in recursive $def expansion
  23 -- Move expandable parameters from ConfigTree.pm to XML config
  24 -- dispersed timeoffsets for monitor
  25 -- use Parallel::ForkManager in devdiscover
  26 -- Set the daemon's log level by signal
  27 -- Selector for Cisco CPU and memory buffer monitoring
  28 -- Option to expand directory view by default
  29 -- Traceroute plugin (Gustavo Torres)
  30 -- CDef Collector plugin (Christian Schnidrig)
  31 -- Optionally show Admin info when authentication disabled
  32 -- RRD Renderer to take CF from the view definition
  33 -- Do we need a separate directory for user-defined styling?
  34 -- Startup script that verifies database consistency at server boot
  35 -- Collector that reports the BerkeleyDB stats
  36 -- Sysedge ntregperf discovery optimization (Shawn)
  37 -- Check RRD DS name length limit (19 bytes) and variable name limit (29 bytes)
  38 -- Better handling of SNMP timeouts in devdiscover
  39 -- MS-SQL SNMP support? (Shawn)
  40 -- Discovery profiles (router, server, etc.) to limit the number of probes
  41 -- Per-tree styling profiles (CSS, color schemas, company name and URL)
  42 -- Describe IF-MIB discovery internals in doc/devdoc/devdiscover.pod
  43 -- New utility to verify the installation files consistency (see below)
  44 -- rrd-create-max for interface counters tunable in vendor modules
  45 -- Backup snapshot of dynamic data (monitor status etc.)
  46 -- Relative path in alias definition
  47 -- "Remember me" login screen option
  48 -- Graph colouring by monitor action
  49 -- Session history display
  50 -- Track changes of XML configurations (XML::Diff, cvs-alike?)
  51 -- Translate parameters in monitor comments
  52 -- Show maximum value in the graph image comments
  53
  54 Design work to do:
  55
  56 -- Design draft for custom indexing and quering
  57 -- Develop a Concept of 95th percentile monthly reports
  58 -- Reports generation (monthly, weekly etc.)
  59 -- Write working draft for "collector-copy" datasource type
  60
  61 To do before Release 1.0.1:
  62
  63 -- Implement monitor escalation (devdoc/wd.monitor-escalation.pod)
  64 -- BUG: template may add children to a leaf
  65 -- Add more documentation to the existing XML
  66 -- Document HTML templates
  67 -- Web interface for ACL editing
  68 -- Date selector in Web interface
  69 -- CSV data export (new Renderer type)
  70 -- Syslog logging
  71
  72 To do someday:
  73
  74 -- Finish and test "RFC2662_ADSL_LINE" and "Paradyne" devdiscover modules
  75 -- Backplane performance for Catalyst switches
  76 -- VoIP dial peer statistics
  77 -- Gradual highlighting for subtree listings
  78 -- Tools for RRD files manipulation (adding/deleting DSes etc.)
  79 -- Service uptime monitoring and reporting (devdoc/wd.uptime-mon.pod)
  80 -- Distributed collector (devdoc/wd.distributed.pod)
  81 -- Log files wraparound
  82 -- Packaging for major OSes: RedHat, Debian, FreeBSD, Solaris, MacOS X (?)
  83 -- rrdtool-1.1 font option (only after rrdtool 1.1.x is released)
  84 -- navigation links to represent the network topology
  85 -- Messaging (devdoc/wd.messaging.pod)
  86 -- Tighter integration with OpenNMS and probably other systems
  87 -- Several obscurity levels instead of hidden=yes/no
  88
  89
  90 (C) 2002-2004, Stanislav Sinyagin <ssinyagin@yahoo.com>
  91
  92 $Id: TODO,v 1.1 2010-12-27 00:03:35 ivan Exp $
  93
  94 ==========================================================================
  95
  96 CC: rrfw-devel@lists.sourceforge.net, "Shawn Ferry" <sferry@sevenspace.com>
  97 From: "Shawn Ferry" <sferry@sevenspace.com>
  98 Subject: Re: [rrfw-devel] health check
  99 Date: Mon, 15 Dec 2003 10:08:35 -0500
 100 To: "Stanislav Sinyagin" <ssinyagin@yahoo.com>
 101
 102 On Dec 15, 2003, at 9:56 AM, Stanislav Sinyagin wrote:
 103
 104 > 'Morning Shawn,
 105 >
 106 > --- Shawn Ferry <sferry@sevenspace.com> wrote:
 107 >>> It might be also that this installation uses old version of
 108 >>> RRFW::Collector::SNMP,
 109 >>> or some buggy version of Net::SNMP.
 110 >>
 111 >> Something like that...When I installed 1.5d I did not stop and
 112 >> restart the collector. It is much happier now.
 113 >>
 114 >> Can you check at each initialization that the versions of all
 115 >> the supporting files is up to date? or maybe stash the modify time
 116 >> of files that are loaded and check.
 117 >>
 118 >> Not an issue just a thought to try and prevent
 119 >> other people from having the same silly problem.
 120 >
 121 > good idea. But I can check the files on disk only, it's not possible
 122 > (not easy) to check if the running process is up to date.
 123 >
 124 > bin/configinfo already prints some versions information.
 125 >
 126 > Let's say, an utility called "bin/checkfiles", would do the following:
 127 >
 128 > -- for files that are simply copied by make install: verify md5 sum
 129 > against that in distribution
 130 >
 131 > -- for files that are modified by make install:
 132 > verify md5 sum against that calculated during make install
 133 >
 134 > -- optionally store and verify md5 sums of user files in
 135 > share/rrfw/discovery and share/rrfw/xmlconfig, as well as
 136 > *-siteconfig.pl
 137 >
 138 > Does someone know if there's already something alike in other software?
 139
 140 Similar functionality exists in cfengine, but I don't think it is
 141 applicable in this case.
 142 Also tripwire.
 143
 144 I am not so worried about knowing if the loaded version is up to date
 145 based on a
 146 stored version string.  Although that was my original thought.
 147
 148 I was thinking that the functionality of the "checkfiles" utility could
 149 just be as you
 150 suggest an md5 sum.  Also, that md5 sum could be stored at
 151 initialization for the libraries
 152 used in any long running process. The next initialization after a
 153 compile could verify
 154 that the on disk sums have not changed.  Possibly to reload, alert or
 155 something.
 156
 157 Shawn
 158
 159 ==========================================================================
 160
 161