Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread Wes Hardaker
> On Tue, 06 Dec 2005 13:51:57 -0500, [EMAIL PROTECTED] said: cnelson> Presently the persistent store for the agent has usmUser which is cnelson> lightly encrypted security information. Note: it's not encrypted at all. It's hex representation of keys and should be made not-readable by anyone

Re: SNMPv1 vs SNMPv2

2005-12-06 Thread Niels Baggesen
On Tue, Dec 06, 2005 at 09:01:24AM -0500, Robert Story wrote: > On 6 Dec 2005 12:00:11 - madhan wrote: > MR> > MR> com2sec mynetwork0 0.0.0.0 public > > don't us 0.0.0.0, use 'default' Or use 0.0.0.0/0 /Niels -- Niels Baggesen - @home - Århus - Denmark - [EMAIL PROTECTED] The purpose of c

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread Dave Shield
> /me is done thinking (yeah, right...) Well, you wouldn't want to overdo it > Issues: > > 1) I don't think we should switch back to root to write files > 2) I think the files should be owned by something other than root if >they need to be written to by an agent running as a different u

Re: agentx race condition?

2005-12-06 Thread John Reardon
On 12/6/05, Robert Story <[EMAIL PROTECTED]> wrote: > Try the patch attached to this bug report: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1337534&group_id=12694&atid=112694 > > If that doesn't help, run the agent and subagent with debug for the agentx > token (and timestamps tu

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread cnelson
> ... > I'd also like to see a hard-coded list of tokens where were > excluded (eg pass). > > We should probably apply this logic to *any* config file which is > writable by anyone other than root. Presently the persistent store for the agent has usmUser which is lightly encrypted security info

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread Wes Hardaker
> On Tue, 6 Dec 2005 10:30:35 -0800 (PST), "David T. Perkins" <[EMAIL > PROTECTED]> said: David> By the way, the StorageType TC is pretty broken (fatally flawed) David> in it's assumptions. That is, really doesn't match the semantics David> of real systems. I hope that the work that is be

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread Wes Hardaker
> On Tue, 6 Dec 2005 13:38:26 -0500, Robert Story <[EMAIL PROTECTED]> said: Robert> On Tue, 06 Dec 2005 09:32:15 -0800 Wes wrote: WH> 1) I don't think we should switch back to root to write files Robert> Ok, but I figured we'd need this up/down-grade capability in Robert> general to allow an

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread Robert Story
On Tue, 06 Dec 2005 09:32:15 -0800 Wes wrote: WH> 1) I don't think we should switch back to root to write files Ok, but I figured we'd need this up/down-grade capability in general to allow an agent to run as non-root most of the time, even on platforms that require root access for access to some

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread David T. Perkins
HI, By the way, the StorageType TC is pretty broken (fatally flawed) in it's assumptions. That is, really doesn't match the semantics of real systems. I hope that the work that is being done by NET-SNMP is not based on trying to duplicate that semantics of the StorageType TC. On Tue, 6 Dec 2005

Re: Problem with ownership of agent persistent stores in v5.2.2

2005-12-06 Thread Wes Hardaker
> On Mon, 5 Dec 2005 07:02:09 -0500, Robert Story <[EMAIL PROTECTED]> said: Robert> Yes, though the persistent store can be written at other times Robert> too. The temporary switch to root would probably be needed in Robert> other scenarios too (I think some platforms use kernel APIs Robert> t

Re: agentx race condition?

2005-12-06 Thread Robert Story
On Tue, 6 Dec 2005 12:12:25 -0500 John wrote: JR> The following sequence causes a problem: JR> snmpd (master agent) starts JR> a remote client is running that polls a few of the subagent's JR> variables once per second. JR> the subagent then starts and registers its variables with the master. JR>

agentx race condition?

2005-12-06 Thread John Reardon
My setup: net-snmp-5.2.2 built by hand for SuSE 9.1 (although the problem occurs on an embedded platform too, so it does not seem to be a platform issue). I am pretty sure that this problem occurs on prior versions, too - although I haven't rigorously proven it - so I don't think it is a 5.2.2 onl

Re: Invoking external commands

2005-12-06 Thread Dave Shield
On Tue, 2005-12-06 at 08:59 -0500, Robert Story wrote: > On Tue, 06 Dec 2005 09:16:19 + Dave wrote: > DS> Having done a bit of work on 'get_exec_output', I don't > DS> think that should be too difficult. But it's definitely > DS> something for 5.4ff, rather than trying to squeeze it in now!

Re: SNMPv1 vs SNMPv2

2005-12-06 Thread Robert Story
On 6 Dec 2005 12:00:11 - madhan wrote: MR> MR> com2sec mynetwork0 0.0.0.0 public don't us 0.0.0.0, use 'default' -- NOTE: messages sent directly to me, instead of the lists, will be deleted unless they are requests for paid consulting services. Robert Story; NET-SNMP Junkie Support:

Re: Invoking external commands

2005-12-06 Thread Robert Story
On Tue, 06 Dec 2005 09:16:19 + Dave wrote: DS> Having done a bit of work on 'get_exec_output', I don't DS> think that should be too difficult. But it's definitely DS> something for 5.4ff, rather than trying to squeeze it in now! So what do you thing is reasonable to fit into 5.3?If there i

SNMPv1 vs SNMPv2

2005-12-06 Thread madhan raj
  Dear All,         I am using Net-SNMP 5.3 pre-release in my router. The configuration file which I am using has the following lines: # Starts Here.. com2sec mynetwork0 0.0.0.0 public group MyRWGroup v1  mynetwork0 rwuser madhan2 priv com2sec mynetwork2 0.0.0.0 public2 group MyROGroup v2c  m

Re: Invoking external commands

2005-12-06 Thread Dave Shield
On Mon, 2005-12-05 at 20:07 -0800, Wes Hardaker wrote: > Dave> (Which then also > Dave> raises the question of whether "pass" output should be > Dave> cached or not). > > Caching... sigh... needed and a pain at the same time. Yup. > I think caching should