2009/2/25 Sergio Cabaço <[email protected]>:
> I'm consulting the RFC 3414 and I'm not finding the place where it is
> described that the initial user can't change its own password.
That's not quite what Wes said. He claimed that:
"...you can't set your password if the
user hasn't been cloned from something else."
But I'm not convinced this is correct either.
The only mention of the need for a valid clone-from user seems
to be in the discussion of creating a new user. In particular:
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding instance
of usmUserCloneFrom.
(from the DESCRIPTION of usmUserAuthKeyChange).
But that is talking about creating a new user, not of changing an
existing instance of any of the various KeyChange objects.
So I'm not convinced that this blanket requirement for a valid
user->cloneFrom field is actually justified.
(Not to mention that things do work once the user entry has been
written out to the persistent snmpd.conf file, and read back in again.
Which implies that there *is* a cloneFrom value at that point.
Where does this come from, and why can't it be set up in the same
way for createUser as well as usmUser?)
Wes - the ball is in your court.
Dave
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
