On 1/24/2007 3:05 PM, Paul Vixie wrote:
glibly said, sir. but i disasterously underestimated the amount of time and money it would take to build BIND9. since i'm talking about a scalable pluggable portable F/L/OSS framework that would serve disparite interests and talk to devices that will never go to an snmp connectathon, i'm trying to set a realistic goal. anyone who want to convince me that it can be done for less than what i'm saying will have to first show me their credentials, second convince david conrad and jerry scharf. (after that, i'm all ears.)
Trying to do a comprehensive monolith will certainly make it a 5-year process. It seems that such an effort is doomed from the start though (as you say, who would fund it?) so I'm not really sure why it would be offered up as the only available outcome. Take a different approach, it wouldn't be that hard to develop the framework alone. The killer for all these things is in the widgets that hang off them, but if the framework was usable and the widgets were easy to write (say, documented better than BIND9's API for example), the users would take care of providing the widgets. Look at all the noobs writing plugins for cacti and spamassassin and... users will write the plugins if the framework is accessible. Don't give me a package that tries to provide everything, give me a daemon with inter-process messaging, event triggers, an extensible OO inheritance model and I'll do my own damn widgets... It wouldn't take five years to write that. It's a summer project. Some of the things I want in an NMS that I can't find in end-all-be-all monolithic packages: self-config stuff default polling cycle authentication data-storage interfaces etc. host/device information static info (hostname, etc) dynamic info (hardware inventory, software inventory, etc) browser interface MIB browser CIM browser others polling events ICMP SNMP GET WBEM script interface TCP connection interface etc. alarm events SNMP traps WBEM notifications syslog eventlog etc. action events alerts (mail, pager, whatever) run local script run remote script manipulate escalation interface event unanswered, chain to other event event cleared, chain to other event reporting browser meters (eg, watch this mib with realtime tachometer) long-term graphing trend analysis/reporting etc. Really it comes down to having a framework in place that can be extended by end-user admins. IOW it's the section heads, not the list items. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/