Charles Hannum writes:
> First of all, it's important to recognize that parsing the output of
> dmesg(8), or anything similar, is a gross hack, and making that more
> friendly is just continuing down the wrong path.

Agreed. I abandoned that idea. I have been playing more recently with
the stuff Jason Thorpe gave me to walk the device tables, but thats
not necessarily a final solution either.

> Here's what I believe we should do:
> 
> Change sysctl(2) to take (in essence) SNMP-like queries.  It's pretty
> similar to this already, but needs some tweaking.  Change things like
> the network statistics to work according to SNMP conventions.

Having sysctl() be extensible and walkable without having to have lots
of preknowledge of what is in the MIB is good. I think that trying to
be SNMPlike is bad. I'm not a big SNMP fan.

> Modify programs like netstat(1) to use SNMP (or just grab the freely
> available tools and use them, where possible).

Ick. I wouldn't mind having netstat use sysctl(), but I think that
going for SNMP is REALLY BAD here. Why? On many machines I run, I need
to get that sort of information out without running any daemons on the
machine -- indeed, all my machines at home listen to the network
minimally if at all. This is important for security at many
sites. Besides, the idea of making system utilities like netstat
dependant on having a daemon running just plain feels bad.

On the other hand, having netstat and other utilities (including ps
and others) use sysctl() could be potentially really good, both from a
point of view of cleanliness of interface and because such utilities
might not need suid privs any more, which can improve security a lot.

> 4) With everything accessible via SNMP, machines can be managed
> remotely.

Again, although this is technically what the standards say you should
do, I'm not sure it actually feels good. I've been in environments
where people have experimented with lots of remote management tools,
and SNMP is great for getting stats off of routers but lousy for
actually altering their configurations -- and it seems like a lose for
running machines.

I would argue that rather than thinking in SNMP terms, we should take
the part that is good -- the idea of having sysctl() support returning
enough information that clients can walk its MIBs extensibly and
cleanly -- and put lots of other stuff in sysctl(). This has all the
advantages you cite and none of the SNMP cruft.

To make implementing SNMP daemons easier, it *might* be a good idea to
make some of the sysctl() network statistics MIBs closer to the SNMP
network management MIBs -- but thats another story.

Perry