From: Dave S. <D.T...@cs...> - 2001-09-03 08:39:31
|
Steve> As an aside, is there a way I could build a static agent that Steve> has v3 support with minimum support files? Wes> Not currently..... Hopefully the Wes> rewrite currently underway will take this into account (right Dave?) Right. Wes> and will let you remove undesired sections of code (like the v1 Wes> support, or the mib parsing, or...) That's certainly the idea. At the moment, I'm still ploughing through the process of getting all the bits *into* the library, so haven't had a chance to look at how to configure them out again. But the overall structure of the new library is keeping this requirement very much in mind, so I don't foresee any major problems. (Hah!) Dave |
From: Dave S. <D.T...@cs...> - 2001-09-20 08:23:33
|
Dave> Wes - in all the time we've been working together, have you ever Dave> known me to rewrite anything to do with this project? Wes> No. Never. Hey, wait a minute, what's that mibJJ directory doing Wes> there? I haven't seen that before. Oh, I must have forgotten about that one. And wasn't there something about splitting the MIB handling at some point, and constructing a registry of MIB modules (first hierarchical and then sequential). And something to do with the way requests were handled in the agent. And I've got a nagging feeling there was something about the MIB parser as well. (HostRes and AgentX don't count, as there was nothing to re-write in the first place). But apart from those few very minor exceptions, I haven't really touched the code much at all. I'm still not quite sure what I'm doing here..... (And you can take that last comment however you like!) Dave |
From: Wes H. <har...@us...> - 2001-09-20 13:30:34
|
>>>>> On Thu, 20 Sep 2001 09:23:27 +0100, Dave Shield <D.T...@cs...> said: Dave> And wasn't there something about splitting the MIB handling at Dave> some point, and constructing a registry of MIB modules (first Dave> hierarchical and then sequential). And something to do with the Dave> way requests were handled in the agent. And I've got a nagging Dave> feeling there was something about the MIB parser as well. Dave> (HostRes and AgentX don't count, as there was nothing to Dave> re-write in the first place). Based on the above summary, you've rewritten 5 things and written 2 from scratch. Which means you generally don't like the way the rest of us do things! (actually, most of the stuff you've rewritten has been from the CMU code). -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-09-24 17:10:32
|
Harrie> - transport, (this I already sent to this list some days ago Harrie> with instructions for the suggested move) Wes> I was going to suggest that we delay that until the merge I think I agree with Harrie here. This is actually the next block that I had my eye on, as being one of the more sensibly organised areas. So it should be pretty quick to bring into the new scheme. The main adjustment would probably be to use the expandable buffer structures. Wes> as the Wes> transports in the main snmplib directory are more advanced and have Wes> been worked on more than the core rewrite. Once the rest of the Wes> rewrite is done, it should be easy to move that code at that time. Do you expect any further significant changes to the transport handling in the main tree? Assuming not, I'll apply Harrie's patch to the new library branch, grab the current main tree, and see about merging the two over the next few days. (I could do with a change from the chaos of the start of year!) Harrie> - config, (should contain default_store, and config file stuff). Wes> I'd probably agree with. Yup - me too. One aim for this block would be to make it as self-contained as possible. Ideally, you should be able to copy this directory into another application, and use the same set of config handlers there - without needing any of the rest of the Net-SNMP code. Harrie> - ksm, (kerberos security module) Harrie> - usm, (user security module) I'd agree that these are sensibly distinct areas. I probably share Wes' question of whether they are sufficiently large to warrent separate directories. I'd also like to see more immediately meaningful names :-) The current code has this as 'snmpv3/user.c' together with 'auth.c' and 'priv.c' (which perhaps should be renamed 'user_auth.c' and 'user_priv' ? ) Similarly, I'd expect that the kerberos handling would be in a file named something like 'kerberos.c' Wes> I don't think they need to be in separate directories. There simply Wes> isn't enough code to warrant it, IMHO. Harrie> - vacm Wes> Similar notion here. I'd suggest putting it in the v3 directory. Or Wes> make a generic acm directory and put it in there. One other thought about the VACM handling. Currently this is only really used within the agent. a) Should this code be present in the library at all? b) or should we try to provide the infrastucture to allow (e.g.) snmptrap/snmptrapd to use it as well? If the latter, then ideally changes to the agent's MIB view of this should be saved in such a way that the other applications could pick them up. I.e. the agent would flush the changes into some form of shared configuration files, that would then be accessible to other VACM-aware applications. Dave |
From: Wes H. <har...@us...> - 2001-09-25 14:10:34
|
>>>>> On Mon, 24 Sep 2001 18:10:24 +0100, Dave Shield <D.T...@cs...> said: Dave> Do you expect any further significant changes to the transport Dave> handling in the main tree? I've written a new transport (the callback one) that I may or may not be done with. So, uh, take that as you will. Dave> Assuming not, I'll apply Harrie's patch to the new library Dave> branch, grab the current main tree, and see about merging the Dave> two over the next few days. (I could do with a change from the Dave> chaos of the start of year!) No merging till: 1) after 4.2.2 2) after you give a 1-2 week announcement before hand saying you'll be doing that (this is a request from John on IRC that I agreed to with the agent api as well). The good news in my mind is that I didn't think you were that close! Dave> I'd also like to see more immediately meaningful names :-) Dave> The current code has this as 'snmpv3/user.c' together with 'auth.c' Dave> and 'priv.c' (which perhaps should be renamed 'user_auth.c' Dave> and 'user_priv' ? ) Dave> Similarly, I'd expect that the kerberos handling would be in Dave> a file named something like 'kerberos.c' NO NO NO! The nice thing about the names "usm" and "ksm" within the files is that they match what people will be looking for after reading the RFCs. It's blatantly obvious that USM goes to RFC2574. Calling it "user" is less obvious, IMHO. I'd like to see that (those) prefix kept "somewhere" within the path component (same with "vacm"). Dave> One other thought about the VACM handling. Dave> Currently this is only really used within the agent. Currently, yes. The trap receiver needs it though (aside from the fact that one of the failings of the SNMPv3 protocol, IMHO, is that they don't have a standardized method of how to accept and authorize traps; we'll have to extrapolate here). Dave> a) Should this code be present in the library at all? You should ask Niels, since he wrote it. I know when I looked at it at one point (a long time ago, because I've forgotten everything now) it made sense why he split it the way he did. Dave> b) or should we try to provide the infrastucture to Dave> allow (e.g.) snmptrap/snmptrapd to use it as well? yes. It's crucially needed. Dave> If the latter, then ideally changes to the agent's MIB view of Dave> this should be saved in such a way that the other applications Dave> could pick them up. I.e. the agent would flush the changes into Dave> some form of shared configuration files, that would then be Dave> accessible to other VACM-aware applications. Assuming you wanted the VACM controls for both applications to be equivalent, which I'm not convinced of. Though they wouldn't *have* to be shared. -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-09-25 16:11:28
|
Dave> Assuming not, I'll apply Harrie's patch to the new library Dave> branch, grab the current main tree, and see about merging the Dave> two over the next few days. Wes> No merging till: Wes> Wes> 1) after 4.2.2 Wes> 2) after you give a 1-2 week announcement before hand saying you'll be Wes> doing that (this is a request from John on IRC that I agreed to Wes> with the agent api as well). Sorry - I wasn't clear. I meant merging the new transport handling into the NEW-LIBRARY branch, rather than the new API into the main line. I quite agree that this needs to be clearly organised beforehand, and can't be a traditional Shield Surprise. Wes> The good news in my mind is that I didn't think you were that close! The bad news is that I'm not! Dave> Similarly, I'd expect that the kerberos handling would be in Dave> a file named something like 'kerberos.c' Wes> NO NO NO! The nice thing about the names "usm" and "ksm" within the Wes> files is that they match what people will be looking for after reading Wes> the RFCs. The horrible thing about names like 'usm' and 'ksm' is that they make absolutely no sense unless you have read (and memorised) the RFCs. Whereas something like 'secmodel/user.c' or 'secmodel/kerberos.c' is pretty clear whether you've read the documents or not. Wes> It's blatantly obvious that USM goes to RFC2574. Hmmm..... you've clearly got a different definition of "blatantly obvious" over that side of the pond :-) OK - the title of that RFC includes both "User-based" and "USM" so it's probably fair to argue either way. But I don't think that 'user' is quite as ridiculous a choice as you seem to imply. And 'ksm' would be meaningless to me, whereas I have at least heard of 'kerberos' [regarding VACM handling in the trap receiver] Dave> If the latter, then ideally changes to the agent's MIB view of Dave> this should be saved in such a way that the other applications Dave> could pick them up. I.e. the agent would flush the changes into Dave> some form of shared configuration files, that would then be Dave> accessible to other VACM-aware applications. Wes> Assuming you wanted the VACM controls for both applications to be Wes> equivalent, which I'm not convinced of. I'm not as familiar with the details of VACM as you and Niels are, but I got the impression from the config handling that you could specify different views for GET, SET and TRAPs - yes? In which case, the agent would only be concerned with *using* the read and write settings, and snmptrapd would only be concerned with using the inform settings. But the agent also implements a MIB view of this information, which is what I'm suggesting should be shared. So if I configure the trap-related entries via SNMP, I'd naively assume that a trap handler running on the same system would take account of them. (Else what's the point of having this table at all!) Dave |
From: Dave S. <D.T...@cs...> - 2001-09-28 15:33:27
|
I haven't really been following this discussion in depth (Anyone who's worked in academia will remember what the first week of term is like, and why I needed to escape for a couple of days!) But what Wes seems to be saying is basically, he trusts NAI Labs to hold the Copyright for this package on behalf of the open-source (orNet-SNMP) community. Is that a fair summary, Wes? In which case, would there be any problem about stating something along this lines explicitly in the Copyright notice? That would seem to cover the twin goals of acknowledging the significant contribution made by NAI Labs, while making it clear that they weren't attempting to restrict ownership or use of the package. I have no idea whether such wording would have any legal standing. And quite frankly, I don't care. The spirit would be pretty clear, and that's fine by me. > The most interesting aspect of all of this (to me, no one else will > understand it as much) is that I trust my current employer to do the > right thing a lot more than I trusted the university system. I have no idea whether trusting NAI Labs is sensible or not - I'm quite willing to trust Wes in trusting NAI. I would agree that it can't be any more foolish than trusting a University, and probably a hell of a lot safer. Universities are bloody good at squeezing every last drop of loyalty and dedication from their staff, without showing any sign of returning that loyalty, or caring too hoots about the well being of such staff. <RANT> Not that this opinion is affected by the current staffing trends within this department. Not at all. Why should I care if the number of students and academic staff have doubled since I've been here - while the number of technical staff has been cut by a third? I'm sure this is perfectly normal management techniques, and it isn't putting any noticeable pressure on the technical staff in the slightest. </RANT> Dave |
From: Wes H. <har...@us...> - 2001-09-29 14:03:18
|
>>>>> On Fri, 28 Sep 2001 16:33:03 +0100, Dave Shield <D.T...@cs...> said: Dave> I haven't really been following this discussion in depth (Anyone Dave> who's worked in academia will remember what the first week of Dave> term is like, and why I needed to escape for a couple of days!) If I were you, I'd have escaped to code instead of this discussion, however I very much appreciate your comments. As mentioned in London, you're the second longest contributor to this project second only to me so your views are invaluable in that regard. Dave> But what Wes seems to be saying is basically, he trusts NAI Labs Dave> to hold the Copyright for this package on behalf of the Dave> open-source (orNet-SNMP) community. Is that a fair summary, Dave> Wes? That's correct. Dave> In which case, would there be any problem about stating Dave> something along this lines explicitly in the Copyright notice? Good question. Have a good set of wording to use and I'll think about it? The other thing I've been thinking about is explicitly stating at the top of the COPYING file that the full list of contributors to the project can be found in the README file. It should be almost complete and and has always been a fairly good list to go by. That might make both sides happy as well. >> The most interesting aspect of all of this (to me, no one else will >> understand it as much) is that I trust my current employer to do the >> right thing a lot more than I trusted the university system. Dave> I have no idea whether trusting NAI Labs is sensible or not - Dave> I'm quite willing to trust Wes in trusting NAI. Well, I did say "more than". I'm not sure I trust anybody entirely these days except myself and my wife. Dave> I would agree that it can't be any more foolish than trusting a Dave> University, and probably a hell of a lot safer. Heh. Maybe you've worked at one a bit too long ;-0 You're beginning to see the light. I think that's when most people leave. Dave> Not that this opinion is affected by the current staffing trends Dave> within this department. Not at all. Why should I care if the Dave> number of students and academic staff have doubled since I've Dave> been here - while the number of technical staff has been cut by Dave> a third? You shouldn't. With the age of computers they should be helping you cut your workload by about 1/6, making the above equation correct, right??? You have my sympathies sir. -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-10-01 16:15:23
|
> Most of the wording in document will stay roughly the same. However, > the primary complaint is that all the participants haven't been > identified properly. I'm not sure that's necessary accurate. I got the impression that a major concern was that NAI appeared to be taking ownership of the project. Not necessarily that they *were*, but that it could seem that they were trying to. Hence my suggestion on Friday about "on behalf of...." > Various copyrights apply to this package, listed in 2 seperate parts > below. Please make sure that you read both parts. The first part is > the copyright for all the code up until 2001, and the second part > applies to the derivative work done since then. I'd suggest that the second bit of this (which you retain) could perhaps be rephrased something like: Various copyrights apply to this package, listed in 2 seperate parts ! below. Please make sure that you read both parts. Up until 2001, + the project was based at UC Davis, and the first part covers all + code written during this time. From 2001 onwards, the project has + been based at SourceForge, and NAI Labs hold the copyright on + behalf of the wider Net-SNMP community, covering all derivative + work done since then. Then add the acknowledgement you suggest: > Code has been > contributed to this project by many people over the years it has > been in development, and a full list of contributors can be found in > the README file under the THANKS section. and (assuming NAI is happy with this wording), then everyone should be satisfied. (Ha!) Dave |
From: Bill S. <wrs...@ze...> - 2001-10-01 16:22:42
|
On Mon, 1 Oct 2001, Dave Shield wrote: > > Most of the wording in document will stay roughly the same. However, > > the primary complaint is that all the participants haven't been > > identified properly. > > I'm not sure that's necessary accurate. > I got the impression that a major concern was that NAI appeared > to be taking ownership of the project. Not necessarily that they > *were*, but that it could seem that they were trying to. Right. Or that NAI appeared to be taking ownership yet didn't have everything in line (copyright transfers, etc.) to do so. > Hence my suggestion on Friday about "on behalf of...." > > > > Various copyrights apply to this package, listed in 2 seperate parts > > below. Please make sure that you read both parts. The first part is > > the copyright for all the code up until 2001, and the second part > > applies to the derivative work done since then. > > I'd suggest that the second bit of this (which you retain) could > perhaps be rephrased something like: > > Various copyrights apply to this package, listed in 2 seperate parts > ! below. Please make sure that you read both parts. Up until 2001, > + the project was based at UC Davis, and the first part covers all > + code written during this time. From 2001 onwards, the project has > + been based at SourceForge, and NAI Labs hold the copyright on > + behalf of the wider Net-SNMP community, covering all derivative > + work done since then. > > Then add the acknowledgement you suggest: > > > Code has been > > contributed to this project by many people over the years it has > > been in development, and a full list of contributors can be found in > > the README file under the THANKS section. > > and (assuming NAI is happy with this wording), then everyone should > be satisfied. (Ha!) Sounds good to me. Take care, Bill |
From: Dave S. <D.T...@cs...> - 2001-10-08 08:48:13
|
> Dave> (Yes, we'll provide backward compatability for legacy modules. > Dave> But the stuff we ship will mostly be the new format.) > > Wow. Does that mean you'll help rewrite a lot of that code??? Of course - how else will I a) get to understand this wierd and wonderful(?) new agent thing; b) get shut of the monstrous load of spaghetti that is the current mibII implementation ? Dave |
From: Dave S. <D.T...@cs...> - 2001-10-08 08:58:57
|
Wes> 1) Dave, the original author, still considers it "beta". And it is, Wes> but it's a rather good beta. More specifically, I regard the mainline CVS tree version as beta. I regard the 4.2.x line code as alpha - reasonably stable alpha, but definitely alpha. Marc> And how would you qualify the maturity of agentx support, because I Marc> intend to use it in real life on a critical application? Read-only, or read-write ? If you plan to delegate a whole MIB sub-tree to a subagent, and use it for monitoring, then I'd probably shrug my shoulders, declare you mildly crazy and wish you the best of luck. That should probably work without too much trouble. If you plan on doing anything more complicated - such as splitting a MIB sub-tree across two or more subagents, or you need to include SET support - particularly if you'll be using the 4.2 line rather than the mainline development tree. Well, I'd have to say you must be sub-clinically neurotic (or as a psychiatrist would say, stark staring bonkers). Dave |
From: Dave S. <D.T...@cs...> - 2001-10-08 09:21:20
|
Wes> If you want to help, you're certainly willing to go read past Wes> discussions on the -coders list (they should be in the archive) Wes> about how we planned on setting up the new mib. If you can't manage to find them, let me know, and I'll dig the relevant messages out of my local archives. Wes> I have a fairly good idea in my head Wes> about what we want to do (carefully divide up the OID tree, lump Wes> things in sections, change the way indexing is done, make many of the Wes> tables read-write, etc). You should probably be aware that I also have a pretty good idea about what we want to do. This is mostly very similar to Wes', but there are bound to be a few places where we will have somewhat conflicting proposals. :-) Dave |
From: Dave S. <D.T...@cs...> - 2001-10-10 08:58:24
|
> I'm rewriting mib2c to use a new writing style that should be much > better in general. Something like the following .... > .... Feedback appreciated. At some point, I'll probably want to sit down and tear apart the structure of the handler routines :-) But assuming you are looking for comments on the basic template idea, you'll be relieved to hear that I think this looks good. A couple of questions/comments: > init_$name(void) > { > table_data *table; I presume that this is presumably copied across verbatim, ... > @foreach $i table@ while this triggers repetition within the generated code. Yes? What's the connection between the internal variable '$i' and the generated code variable 'table' in this line? Or are the two occurances of 'table' not the same thing at all? (in which case you probably know what my suggestion would be....) What values will '$i' run through? > table = create_table_data("$i"); The '$i' here is presumably replaced by the value from the loop above. How would this be distinguished from a literal $ character that should be copied across to the generated code? I'm not objecting to this basic idea. The only thing that slightly concerns me is that this interpolation looks almost *too* natural. The control constructs are clearly indicated as such (using the @ syntax). But this interpolation is done separately, tucked away within normal code, and looking practically identical. A syntax such as table = create_table_data("@$i@"); might make it slightly clearer what is interpolated, and what isn't. But basically, I think this looks good. Dave |
From: Wes H. <har...@us...> - 2001-10-10 15:04:12
|
>>>>> On Wed, 10 Oct 2001 09:58:17 +0100, Dave Shield <D.T...@cs...> said: >> init_$name(void) >> { >> table_data *table; Dave> I presume that this is presumably copied across verbatim, ... Only $XXX variables are translated. You get a couple for free (like $name being the file name) and the rest you have to define using statements (like @foreach ...@). >> @foreach $i table@ Dave> while this triggers repetition within the generated code. Yes? Yep. Dave> What's the connection between the internal variable '$i' and the Dave> generated code variable 'table' in this line? It loops through all known tables. IE, if you specified the mibII tree it would loop through all the tables within that section of the mib tree (far too many in number, but hey, that's their fault). Dave> Or are the two occurances of 'table' not the same thing at all? Dave> (in which case you probably know what my suggestion would be....) Dave> What values will '$i' run through? If run on mibII, $i would iterate over (sysORTable, ifTable, udpTable, ...) >> table = create_table_data("$i"); Dave> The '$i' here is presumably replaced by the value from the loop above. Dave> How would this be distinguished from a literal $ character that should Dave> be copied across to the generated code? Well, the nice thing about $ signs is that they're not used much in C. And I doubt we'll be writing any financial mib support directly in the mib2c templates. However, something like \$ would probably work. Dave> I'm not objecting to this basic idea. The only thing that Dave> slightly concerns me is that this interpolation looks almost Dave> *too* natural. The control constructs are clearly indicated as Dave> such (using the @ syntax). But this interpolation is done Dave> separately, tucked away within normal code, and looking Dave> practically identical. A syntax such as Dave> table = create_table_data("@$i@"); Dave> might make it slightly clearer what is interpolated, and what isn't. Dave> But basically, I think this looks good. Either is fine with me. I'd leave it short just for ease of use, but I'd be happy to change it if a third party stepped forward ;-) -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-10-10 15:36:37
|
> Dave> What's the connection between the internal variable '$i' and the > Dave> generated code variable 'table' in this line? > > It loops through all known tables. IE, if you specified the mibII > tree it would loop through all the tables within that section of the > mib tree Ah - so it's tables in the MIB, rather than somethings in a table. OK. Suggestion - perhaps this should be @foreach $i tables@ // plural or even @foreach $table tables@ // meaningful variable name or even @foreach $table TABLES@ // recognisable keyword Any of these would also address my concern over the same name being used for a local variable, and a meta-config keyword: > Dave> Or are the two occurances of 'table' not the same thing at all? > Dave> (in which case you probably know what my suggestion would be....) > Dave> The '$i' here is presumably replaced by the value from the loop above. > Dave> How would this be distinguished from a literal $ character that should > Dave> be copied across to the generated code? > > Well, the nice thing about $ signs is that they're not used much in > C. And I doubt we'll be writing any financial mib support directly in > the mib2c templates. However, something like \$ would probably work. Hmmm..... yeah, OK. Unless anyone else thinks use of $ is likely to bite us, then I'm happy to go with that sort of escape mechanism. One final request - can the new mib2c please treat an invalid invocation as an error, rather than generating code for the main mibII tree. Ideally "mib2c mymib.txt" should choose a sensible starting point from within that file. Failing that, it should throw an error. But the current behaviour of generating code for the mib2 tree instead is (how can I put this?).... somewhat counter-intuitive :-) Dave |
From: Wes H. <har...@us...> - 2001-10-23 22:13:59
|
>>>>> On Wed, 10 Oct 2001 16:36:31 +0100, Dave Shield <D.T...@cs...> said: Dave> Suggestion - perhaps this should be Dave> @foreach $i tables@ // plural I actually don't like that, but regexps are great so both are now supported. Dave> @foreach $table tables@ // meaningful variable name Bah. Meaningful variable names. Pluheeeasse. Dave> @foreach $table TABLES@ // recognisable keyword Dave> One final request - can the new mib2c please treat an invalid Dave> invocation as an error, rather than generating code for the main Dave> mibII tree. It already handled that even before you asked: % ./mib2c -c mib2c.iterate.conf ifTable writing to ifTable.h writing to ifTable.c running indent on ifTable.h running indent on ifTable.c % ./mib2c -c mib2c.iterate.conf xxx you didn't give me a valid OID to start with at ./mib2c line 75. % ./mib2c -c mib2c.iterate.conf you didn't give me a valid OID to start with at ./mib2c line 75. Dave> Ideally "mib2c mymib.txt" should choose a sensible starting point Dave> from within that file. Ack. sigh... -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-10-12 13:56:52
|
> Dave> struct netsnmp_session_s { > ... > Dave> netsnmp_handlers *handlers; // the 'hook_xxx' routines > ... > Dave> } > > I've been to busy to follow this thread entirely yet, but the one > point that caught my attention was the above. I'd appreciate it if > you not call the hooks "handlers", Sure. > Any chance we could use "hooks" instead, or some other word > like that? Fine by me. I don't really care about what things are called (as long as it's reasonably sensible). I'm much more interested in the functionality and organisation. Dave |
From: Wes H. <har...@us...> - 2001-10-12 14:25:29
|
>>>>> On Fri, 12 Oct 2001 14:56:47 +0100, Dave Shield <D.T...@cs...> said: Dave> I don't really care about what things are called (as long as Dave> it's reasonably sensible). I'm much more interested in the Dave> functionality and organisation. Me too. Exactly the reason I want the name changed, because otherwise we'd have 500000000 messages saying "I added by mib handler to the handler list within the snmp_session and it segfaulted". -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-10-15 08:46:03
|
Vinay> You could define a MIB table and log error code and error Vinay> description keyed by req_id of the PDU, ip adress of the PDU, Vinay> address type of the PDU. If there is a SET failure, manager Vinay> could do a GET to read the row in this table. Wes> That would work too, though I personally would rather use a trap since Wes> it's much more likely any trap receiver will display and log the Wes> message, where as most managers without knowledge of that particular Wes> agent won't go look into the private MIB displaying the errors. But then the manager would need to a) know where that particular agent directed traps to, and b) have access to that location A table-based history of recent failures has the advantage of potentially being accessible from anywhere. Remember that the person administering the agent, and the person administering the management application are not necessarily the same (or even on speaking terms!) Dave |
From: Wes H. <har...@us...> - 2001-10-15 13:44:11
|
>>>>> On Mon, 15 Oct 2001 09:45:57 +0100, Dave Shield <D.T...@cs...> said: Dave> But then the manager would need to Dave> a) know where that particular agent directed traps to, and Dave> b) have access to that location c) use the standardized SNMP-NOTIFICATION-LOG-MIB (or whatever its called) to log it locally as well, which is at least a standard method for doing logging notices. -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-10-15 14:28:40
|
Dave> But then the manager would need to Dave> a) know where that particular agent directed traps to, and Dave> b) have access to that location Wes> c) use the standardized SNMP-NOTIFICATION-LOG-MIB (or whatever its Wes> called) to log it locally as well, which is at least a standard Wes> method for doing logging notices. "locally" meaning where? The box with the agent on it, or the box where the query was run from? Because there's nothing to say that the manager has direct (non-SNMP) access to the box with the agent on at all. And if the manager is mobile, they might easily be moving around and using a selection of different boxes to work from. It feels a lot of overhead to have to set up an entry in the notification table, make the query, and then remove the notification entry every time. :-) I'm not trying to suggest that there _isn't_ a role for trap-based reporting of problems - simply that this isn't necessarily the most appropriate approach in all circumstances. Dave |
From: Wes H. <har...@us...> - 2001-10-15 14:46:54
|
>>>>> On Mon, 15 Oct 2001 15:27:28 +0100, Dave Shield <D.T...@cs...> said: Wes> c) use the standardized SNMP-NOTIFICATION-LOG-MIB (or whatever its Wes> called) to log it locally as well, which is at least a standard Wes> method for doing logging notices. Dave> "locally" meaning where? Dave> The box with the agent on it, or the box where the query was run from? agent. Dave> I'm not trying to suggest that there _isn't_ a role for Dave> trap-based reporting of problems - simply that this isn't Dave> necessarily the most appropriate approach in all circumstances. I was merely trying to stick with a method that more managers would be able to handle (IE, a less proprietary-mib). -- Wes Hardaker Please mail all replies to net...@li... |
From: Dave S. <D.T...@cs...> - 2001-10-22 08:58:04
|
Dave> I don't *think* [changing the size of magic] will break anything. Wes> Binary compatibility will break and possibly other 3rd party Wes> modifications to local structures, but that may not matter in your Wes> case. We talked about this a number of years back and decided *not* Wes> to make the change within the core agent code as we couldn't say that Wes> some set of people wouldn't get upset Oh, I agree. I was only suggesting that Ilann could safely make this change in his private code. I didn't mean to imply that we'd be doing the same in the main project code. Question: Does the v5 agent have a similar sort of restriction? Dave |
From: Wes H. <har...@us...> - 2001-10-22 14:41:16
|
>>>>> On Mon, 22 Oct 2001 09:58:00 +0100, Dave Shield <D.T...@cs...> said: [re: magic numbers] Dave> Question: Does the v5 agent have a similar sort of restriction? nope. But the default method of doing things is to register each node instead. I've actually wanted to put in some sort of "magic" number if people wanted it, but it hasn't been needed. -- Wes Hardaker Please mail all replies to net...@li... |