On Saturday 22 January 2005 12:42 am, Tuc wrote:
> Hi,
>
> If I might contribute......
>
> > > 2. The modularization boundary should be a MIB. Rather than tailor
> > > snips to read /proc directly, it would be better to manufacture a client
> > > app that translates /proc data into SNMP MIB format. (there have been
> > > some efforts in this regard previously, but I don't have a trace).
> >
> > that's what SNMP agent does.
> >
> > and snmpmon and it's collector garter that data. It's slightly broken, but the base code is there waiting for somebody to fix.
> > no custom sotfware needs to be installed on the hosts.
> > Designed to work for hosts with Net-SNMP installed like Solaris or Linux and Windows (with snmp enabled), and AFAIK for ciscos.
> >
> >
> I disagree that SNMP is the way to go for servers.
>
> For portability and extensibility I think the way hostmon is
> doing things currently is a good way to go about it. While for some
> companies loading something like Perl onto a machine is not allowed, I
> think this is preferable over SNMP. SNMP needs to be bound to a port
> < 1024 which means you need to be root to start it. It also means
> that exploits will potentially have root access.
theoretically yes.
in practice SNMP model has access control, encryption and authentification. hostmon lacks all of those (except ACL)
snmpd code is also by far better tested and patches are available in case of problems - hostmon lacks all that too.
SNMPd is standart and supported part of most OSes - hostmon is not.
adding/configuring snmpd as part of jumstart/kickstart is trivial and supported.
many system management tools require running SNMP agent anyway.
snmp agent is also lighter then hostmon, doesn't fork processes, doesn't hang on resources as hostmon does (mounts, dns resolution, etc)
yes hostmon is easier for older OSes that don't have snmp agent with Host MIB.
>
> Doing things the way that they currently are, using Perl with
> shells out to system provided binaries means that as long as base perl
> is installed, and the base OS is installed, that the client will work.
> Leaving it on the port it currently is (5355) also means it can be
> started by a user with a uid/gid that does not have to include root.
>
> If we were to go SNMP, there becomes the issue of the SNMP itself,
> and the MIBs, and its portability across platforms. If we were to specify
> a certain one, we would be forcing people to use something that they might
> need another SNMP client on instead. We also can not be guaranteed that the
> agents available on the target platform have the extensibility we would want.
> If they do, then we would have to program towards that.
>
HOST SNMP MIB is in RFC, but output of vmstat netstat etc is not.
see hostmon code and you'll see how people are fighting with output of multiple versions of vmstat (SunOS,Solaris,Linux, RHEL,)
but hostmon has things that snmp agent doesn't have - like mailq (maybe sendmail MIB has it?)
(hovewer mailq output is broken in RHEL linux - there is permission issue)
> I think on networking equipment SNMP works great, but for systems
> I think the current Perl/system utils is the way to go.
It is easier, that's true. especially due to the fact that many MNS sofware vendors take this shortcut and just keep scripting that in shell/perl
as oppose to do it the right way :-)))))
>
> Tuc/TTSG Internet Services, Inc.
>
> (PS - Besides, I multiply my load by 100 and change my refresh
> down to 4 minutes... And I know how to do that in perl. ;) )
when chaning your refresh make sure you recreate RRD, it doesn't like changes in time intervals.
>
|