Ok, you're right. I have read Wes answer again and it was written with the meaning of what you've just said and not by the way I've read it. Thanks for the correction. I was misinterpreting his answer.
So, in this case, I can change the source code in some of the places that you've pointed to obtain what I want. There is no specification in the RFC that says that initial master user can't change its own password in the first boot or is it? The passw can be change on all boots, except in the one when createUser is converted to usmUser in the persistent snmpd.conf. I think this happens because it needs to insert the new created user in the "user's table" and only then the passwords can be changed. This only occurs when the agent goes down and gets up. What I'll try to do is to make this "actualization" when the createUser is converted in usmUser although I've not found a way of doing that yet. Thank you very much, Sérgio Cabaço -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dave Shield Sent: quarta-feira, 25 de Fevereiro de 2009 11:13 To: Wes Hardaker; Sergio Cabaço Cc: [email protected] Subject: Re: Changing password first boot 5.3.2 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
