On 20 July 2010 18:03, Bart Van Assche <[email protected]> wrote: > Every major project I know of keeps configuration files that are rewritten > by software and configuration files that have been created manually > separate.
Exactly. We have the same distinction. (/etc/snmp/snmpd.conf and /var/net-snmp/snmpd.conf) I would envisage this functionality being handled in a similar way to createUser today. If an "extend" (or similar) directive was placed in the /var/net-snmp/snmpd.conf file. then it could be updated via SET requests, and the changes would be saved when the agent shut down. If the extend directive was read in from a static config file (as is currently the case), then it would be read-only. > It is possible with VACM to close the security hole that would be > created by making nsExtendArgs modifiable. First thing - nsExtendArgs *is* modifiable - see the MIB definitions. Entries can be set up dynamically via SET requests, and such entries can also be amended on the fly. It's only (static) config file entries that are marked as read-only. That wouldn't change. > But users won't like it that upgrading to a newer Net-SNMP version > would create a security hole unless they modify their snmpd.conf. The change that is proposed would only affect entries set up via the dynamic snmpd.conf file That's not currently a supported mechanism (although it would probably work). So we're talking about new config entries, that were deliberately placed here. It wouldn't affect existing configurations. Or that's how I'd see it, anyway. Dave ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
