--> slam has joined #net-snmp
--> Debolaz has joined #net-snmp
--> jbpn has joined #net-snmp
--> djHD has joined #net-snmp
[2002/09/10 04:55:04] #net-snmp <djHD> hello guys
--> benr has joined #net-snmp
[2002/09/10 04:57:29] #net-snmp <djHD> can someone explain how to implement setable variables ? AGENT.txt is not clear to me
[2002/09/10 04:57:40] #net-snmp <djHD> i write code myself and dont use mib2c
[2002/09/10 04:58:28] #net-snmp <djHD> there is even no information what to return on success from write_method
[2002/09/10 04:58:37] #net-snmp <djHD> but i assume its 0
[2002/09/10 04:59:30] #net-snmp <djHD> and also I would like to get a username who query my agent
[2002/09/10 05:03:13] #net-snmp <djHD> i set write_method in SnmpDispatch , but this write method called 4 times on 1 set
[2002/09/10 05:03:39] #net-snmp <djHD> i dont do anything in this write , simply ret 0
[2002/09/10 05:15:47] #net-snmp <djHD> i found, 4 times but with different actions ...
--> wes has joined #net-snmp
--> TrogL has joined #net-snmp
[2002/09/10 07:57:08] #net-snmp <TrogL> morning. I didn't get any response from net-coders on my MAX_FILESYSTEMS issue (maximum of 100, but I've got more, crashing the daemon)
[2002/09/10 07:57:10] #net-snmp <TrogL> now what?
[2002/09/10 08:01:35] #net-snmp <jbpn> send your message to net-snmp-users AND net-snmp-coders at intervals of 2 hours until someone answers
[2002/09/10 08:01:50] #net-snmp <rstory> make sure you use html mail, too
[2002/09/10 08:01:57] #net-snmp <rstory> AND TYPE IN ALL CAPS
[2002/09/10 08:02:02] #net-snmp <jbpn> and attach some huge debugging logs
[2002/09/10 08:02:26] #net-snmp <jbpn> heh heh
[2002/09/10 08:02:31] #net-snmp <jbpn> that wasn't very helpful
[2002/09/10 08:02:31] #net-snmp <rstory> ;-)
[2002/09/10 08:02:46] #net-snmp <jbpn> what happens if you just up the value and recompile?
--> urgusabic has joined #net-snmp
[2002/09/10 08:21:30] #net-snmp <TrogL> well, I personally would be just fine, except....
[2002/09/10 08:21:39] #net-snmp <TrogL> 1. I'm probably not the only person in this boat
[2002/09/10 08:21:55] #net-snmp <TrogL> 2. I'd have to re-fix it every time there'sa new release and...
[2002/09/10 08:22:06] #net-snmp <TrogL> 3. since I'm on the CVS tree, that theoretically is every day
[2002/09/10 08:22:26] #net-snmp <jbpn> but, if you tell us that it works, then we can just make the fix...
[2002/09/10 08:22:29] #net-snmp <TrogL> so i would be devoting the rest of my professional life to re-fixing this problem
[2002/09/10 08:24:42] #net-snmp <jbpn> since I don't think any of the developers has a machine with that many filesystems, we need your help on this one
[2002/09/10 08:25:20] #net-snmp <TrogL> and who, pray tell, is going to tell all those poor souls who hard-coded the values of HRS_TYPE_SWAP that we've changed their world?
[2002/09/10 08:27:13] #net-snmp <TrogL> to see what I'm talking about, look at agent/mibgroup/host/hr_storage.h
[2002/09/10 08:27:38] #net-snmp <TrogL> look for HRS_TYPE_FS_MAX and the next 7 lines
[2002/09/10 08:28:03] #net-snmp <jbpn> yes I see -- but I don't understand why they have anything to do with the number of filesystems
[2002/09/10 08:28:11] #net-snmp <jbpn> strange
[2002/09/10 08:28:41] #net-snmp <TrogL> because the number of filesystems has been artifically MAX'd at 100
[2002/09/10 08:28:44] #net-snmp <TrogL> and i've got 117
[2002/09/10 08:29:08] #net-snmp <TrogL> so when snmpwalk (or WUG) asks for the next one after 99, it breaks
[2002/09/10 08:29:52] #net-snmp <jbpn> yes
[2002/09/10 08:30:15] #net-snmp <TrogL> so yes, I can submit a patch adding 100 to everything and make it nice and pretty for me
[2002/09/10 08:30:20] #net-snmp <jbpn> yes
[2002/09/10 08:30:33] #net-snmp <jbpn> and the problem would be...
[2002/09/10 08:30:39] #net-snmp <TrogL> but if somebody else (remember there are other people using this code) has written stuff
[2002/09/10 08:30:59] #net-snmp <TrogL> expecting to access HRS_TYPE_SWAP and 102, and I've gone and changed it to 202...
[2002/09/10 08:31:05] #net-snmp <TrogL> s/and/at/
[2002/09/10 08:31:49] #net-snmp <TrogL> and supposing my powers that be go out and buy ANOTHER damn jukebox, I'm right back where I started
[2002/09/10 08:31:58] #net-snmp <jbpn> ok
[2002/09/10 08:32:22] #net-snmp <jbpn> well that's a tough one
[2002/09/10 08:32:52] #net-snmp <TrogL> with the advent of inexpensive disk arrays, I'm surprised this hasn't come up before
[2002/09/10 08:33:22] #net-snmp <TrogL> ie. SAN's
[2002/09/10 08:33:40] #net-snmp <jbpn> i would guess that if it has, people have just upped the values
[2002/09/10 08:34:12] #net-snmp <TrogL> I supposed we could make FS_MAX a truly ludricrous value but the whole concept leaves a bad tastes in my mouth
[2002/09/10 08:35:03] #net-snmp <TrogL> the whole purpose seems to be to lock in the value of HRS_TYPE_MEM etc.
[2002/09/10 08:35:36] #net-snmp <TrogL> I'm i'm suspecting they want to be able to keep the value of counters within an int
[2002/09/10 08:35:54] #net-snmp <TrogL> but if so, why not just go for HRS_TYPE_MAX = 255 and be damned
[2002/09/10 08:36:16] #net-snmp <jbpn> I wouldn't read too much into it
[2002/09/10 08:37:45] #net-snmp <TrogL> why else have a HRS_TYPE_FS_MAX at all?
[2002/09/10 08:38:20] #net-snmp <TrogL> for that matter, why not have a separate category for MEM, SWAP and MBUF rather than trying to have it to double-duty?
[2002/09/10 08:39:10] #net-snmp <jbpn> there *is* a separate category, which is why the index value doesn't much matter
[2002/09/10 08:39:17] #net-snmp <TrogL> that way you could have infinity-1 filesystems and nobody would give a damn
[2002/09/10 08:40:08] #net-snmp <jbpn> it would make more sense to put the "special" values at the beginning of the table
[2002/09/10 08:40:17] #net-snmp <jbpn> but -- I didn't write the code
[2002/09/10 08:40:58] #net-snmp <jbpn> So, what I would say is -- changing the values to a bigger (but still fixed) constant will not break any properly written management application.
[2002/09/10 08:41:01] #net-snmp <TrogL> I don't consider MEM, SWAP or MBUF to even be "storage"
[2002/09/10 08:41:13] #net-snmp <jbpn> Well, the HOST-RESOURCES-MIB does.
[2002/09/10 08:42:03] #net-snmp <TrogL> well, then, it's badly written - who do I bitch at?
[2002/09/10 08:42:13] #net-snmp <jbpn> Hmmm....
[2002/09/10 08:42:48] #net-snmp <jbpn> If you read the definitions, it actually makes a lot of sense.
[2002/09/10 08:44:08] #net-snmp <TrogL> ACTION is looking at it now
[2002/09/10 08:45:28] #net-snmp <TrogL> i don't see why a special case couldn't have been made for memory and swap - all systems have them
[2002/09/10 08:45:45] #net-snmp <jbpn> not all systems have swap
[2002/09/10 08:45:53] #net-snmp <jbpn> not all systems have disks
[2002/09/10 08:46:04] #net-snmp <jbpn> so why bother with special cases?
[2002/09/10 08:46:05] #net-snmp <TrogL> true
[2002/09/10 08:46:54] #net-snmp <TrogL> hrStorageIndex is defined as Integer32, highest value 2147483647
[2002/09/10 08:47:09] #net-snmp <jbpn> yes
[2002/09/10 08:47:11] #net-snmp <jbpn> is that enough?
[2002/09/10 08:47:30] #net-snmp <TrogL> jeez - I hope so
[2002/09/10 08:47:55] #net-snmp <jbpn> just checking ;-)
[2002/09/10 08:48:11] #net-snmp <TrogL> so why pick a piddling number like 100? 65535 was available
[2002/09/10 08:48:55] #net-snmp <jbpn> I would imagine (caveat: speculation) that the code maintains an array of structures of size HR_..MAX
[2002/09/10 08:49:07] #net-snmp <jbpn> so picking a stupidly big number will typically just waste a lot of memory
[2002/09/10 08:49:30] #net-snmp <jbpn> the right solution is probably to:
[2002/09/10 08:49:41] #net-snmp <jbpn> move the special types to the start of the table
[2002/09/10 08:49:52] #net-snmp <jbpn> and then have a linked list of filesystems
[2002/09/10 08:49:54] #net-snmp <jbpn> but
[2002/09/10 08:50:10] #net-snmp <jbpn> this is a major rewrite of code that no single individual has a really good handle on.
[2002/09/10 08:50:12] #net-snmp <jbpn> so
[2002/09/10 08:50:17] #net-snmp <jbpn> don't hold your breath
[2002/09/10 08:52:02] #net-snmp <TrogL> there's no "keeper of the code" on HOSTS?
[2002/09/10 08:52:31] #net-snmp <jbpn> not particularly as far as I am aware
[2002/09/10 08:53:38] #net-snmp <jbpn> I think Dave did the original implementation but it's seen quite a lot of patching since then for portability
[2002/09/10 08:54:31] #net-snmp <TrogL> and what code, besides the daemon, would be affected? snmpwalk seems to merely ask for the next value
[2002/09/10 08:54:48] #net-snmp <jbpn> yes
[2002/09/10 08:54:57] #net-snmp <jbpn> just badly written management applications
[2002/09/10 08:55:08] #net-snmp <jbpn> (not anything that we distribute)
[2002/09/10 08:55:20] #net-snmp <jbpn> I would be surprised if it affected anything actually
[2002/09/10 08:56:23] #net-snmp <TrogL> I'm taking that a "well written" management application would pick up the variable values from hr_storage.h rather than relying upon hardcoded valeus?
[2002/09/10 08:56:55] #net-snmp <jbpn> no no, it wouldn't assume anything, it would look at the hrStorageType field, not the index, to work out what it was looking at.
[2002/09/10 08:58:00] #net-snmp <TrogL> WUG isn'
[2002/09/10 08:58:02] #net-snmp <TrogL> isn'
[2002/09/10 08:58:03] #net-snmp <TrogL> shit
[2002/09/10 08:58:15] #net-snmp <TrogL> What's Up Gold doesn't even return hrStorageType
[2002/09/10 08:58:15] #net-snmp <jbpn> how can you tell?
[2002/09/10 08:58:44] #net-snmp <jbpn> well, it probably doesn't matter then anyway
[2002/09/10 08:59:13] #net-snmp <TrogL> my issue was with snmpwalk anyway
[2002/09/10 09:00:22] #net-snmp <TrogL> I was hoping to go look for your "array" and see how bad a job it was fixing it
[2002/09/10 09:01:24] #net-snmp <jbpn> (if it doesn't *care* what the storage type is, moving things around a bit doesn't matter to it)
[2002/09/10 09:01:24] #net-snmp <jbpn> it's only a problem if it *assumes* that hrStorageTable.101 corresponds to the entry for memory
[2002/09/10 09:01:35] #net-snmp <jbpn> cool! go for it
[2002/09/10 09:02:11] #net-snmp <TrogL> it seems to be primarily limited to hr_storage.c
[2002/09/10 09:02:33] #net-snmp <jbpn> should be
[2002/09/10 09:03:06] #net-snmp <TrogL> is it a valid assumption that applications compiled --with-mib-modules="host" would be the only ones interested in this code?
[2002/09/10 09:03:26] #net-snmp <jbpn> yes
[2002/09/10 09:03:43] #net-snmp <jbpn> (basically this means just snmpd)
[2002/09/10 09:04:22] #net-snmp <jbpn> snmpwalk doesn't know or care about this stuff
[2002/09/10 09:04:45] #net-snmp <TrogL> then only hr_storage.c (and possibly hr_filesys.c) appear to be affected
[2002/09/10 09:05:06] #net-snmp <jbpn> that's what I'd expect
[2002/09/10 09:06:24] #net-snmp <TrogL> looks like I need to look at RFC1514 - comments in hr_filesys.c indicate problems with the implementation
[2002/09/10 09:07:42] #net-snmp <TrogL> "hrFSIndex must remain constant at least from one re-initialization...to the next"
[2002/09/10 09:08:20] #net-snmp <TrogL> hmmm...perhaps I've found my life's work
[2002/09/10 09:09:04] #net-snmp <TrogL> oh lovely
[2002/09/10 09:09:15] #net-snmp <TrogL> "Consider indexing the non-file-system-based storage entries first"
[2002/09/10 09:09:33] #net-snmp <TrogL> great minds think alike
[2002/09/10 09:09:50] #net-snmp <jbpn> where does it say that?
[2002/09/10 09:10:13] #net-snmp <TrogL> hr_filesys.c
[2002/09/10 09:10:18] #net-snmp <jbpn> ah
[2002/09/10 09:10:32] #net-snmp <jbpn> heh heh
[2002/09/10 09:11:56] #net-snmp <TrogL> in Get_Next_HR_FileSys
[2002/09/10 09:15:11] #net-snmp <TrogL> I suppose for a temporary fix i could propose making the old 101 102 and 103 to be 1 2 and 3 and boost MAX up to 256
[2002/09/10 09:15:43] #net-snmp <TrogL> but I'd like a better approach as there is mention of a more complex memory scheme than just MEM
[2002/09/10 09:23:19] #net-snmp <TrogL> no arrays so far
[2002/09/10 09:24:38] #net-snmp <TrogL> I feel the need for some sort of consensus before doing anything this drastic
[2002/09/10 09:24:50] #net-snmp <TrogL> my first attempt at cage rattling came up empty
[2002/09/10 09:24:53] #net-snmp <TrogL> rant?
[2002/09/10 09:29:04] #net-snmp <TrogL> if you look at http://www.faqs.org/rfcs/rfc1514.html
[2002/09/10 09:29:41] #net-snmp <TrogL> there are separate categories for various types of storage
[2002/09/10 09:30:17] #net-snmp <TrogL> eg. other, RAM, virtual, floppy etc. why aren't we using those instead of the generic "storage"?
[2002/09/10 09:31:23] #net-snmp <TrogL> or am I misunderstanding the usage?
[2002/09/10 09:45:12] #net-snmp <TrogL> ACTION is misunderstanding the usage
--> wildbill has joined #net-snmp
--> wildbill has joined #net-snmp
--> benr has joined #net-snmp
--> mike has joined #net-snmp
--> treynolds has joined #net-snmp
--> Debolaz has joined #net-snmp
--> Debolaz has joined #net-snmp
--> Debolaz has joined #net-snmp
--> benr has joined #net-snmp
[2002/09/10 22:44:45] #net-snmp <benr> ACTION is away: quake time.
--> jbpn has joined #net-snmp

Powered by: