--> ziggurat has joined #net-snmp
--> EvalBMS has joined #net-snmp
--> clever has joined #net-snmp
--> Abracadabra has joined #net-snmp
[2008/08/27 03:09:10] #net-snmp <Abracadabra> hi
[2008/08/27 03:09:44] #net-snmp <Abracadabra> I am new to SNMP....
[2008/08/27 03:10:03] #net-snmp <Abracadabra> is net-snmp a proprietary tool ?
--> shakespear has joined #net-snmp
[2008/08/27 03:23:51] #net-snmp <shakespear> hi - I am running net-snmp on redhat el 4 Update 5 - and snmpwalk is now VERY VERY :) slow (in addition the io-wait time on the machine ist increasing dramatically). Anyone other observing something similar?
[2008/08/27 03:26:50] #net-snmp <jsafrane> Abracadabra: net-snmp is open-source implementation of SNMP agent and client tools
[2008/08/27 03:27:11] #net-snmp <jsafrane> shakespear: update 5 is quite old, try the newest one
[2008/08/27 03:28:23] #net-snmp <Abracadabra> jsafrane, I have just started a job that requires me to learn and master SNMP, but honestly, eventhough there are plenty of ressources around, none cover a simple yet effective way for me to get to grasps with the concept
[2008/08/27 03:29:17] #net-snmp <Abracadabra> MIBS, OIDs, and the use of traps, etc...
[2008/08/27 03:31:26] #net-snmp <shakespear> jsafrane: thx - you are right / unfortunatelly the update policy is not under my control - I will try to enforce Update 7
[2008/08/27 03:31:43] #net-snmp <jsafrane> Abracadabra: it's not that difficult... try to google something like "snmp tutorial" or so.
[2008/08/27 03:32:48] #net-snmp <jsafrane> Abracadabra: the logic is very simple, but the terminology aroung is ... not intuitive :)
[2008/08/27 03:34:14] #net-snmp <jsafrane> shakespear: if you use RHEL, then please contact your support, that's what you pay them for... but just for this moment: https://bugzilla.redhat.com/show_bug.cgi?id=241581 (and update to 4.7 is *highly* recommended)
[2008/08/27 03:37:26] #net-snmp <Abracadabra> jsafrane, you're absolutely right
[2008/08/27 04:54:45] #net-snmp <shakespear> jsafrane: we had contact with the support - and we didn't receive any "useable" answer ... => i.e. the hint with bug ud 241581 ... thank your very much!!
--> af_ has joined #net-snmp
--> hardaker has joined #net-snmp
--> af_ has joined #net-snmp
--> splitbrain has joined #net-snmp
[2008/08/27 06:21:11] #net-snmp <splitbrain> hi
[2008/08/27 06:22:34] #net-snmp <splitbrain> can anyone give me a quick hint what the easiest way to get the engineid of the locally running snmpd is?
--> darnok has joined #net-snmp
[2008/08/27 06:35:17] #net-snmp <rstory> splitbrain: snmpget -v2c -c public localhost SNMP-FRAMEWORK-MIB::snmpEngineID.0
[2008/08/27 07:09:01] #net-snmp <splitbrain> rstory, thanks. Could I do this programatically from within a subagent?
[2008/08/27 07:10:34] #net-snmp <rstory> errr... it might work, as long as the subagent isn't processing a set request (that would cause a deadlock)
[2008/08/27 07:14:51] #net-snmp <splitbrain> hmm okay. does that mean I have to open a new snmp_session to connect to the daemon, or is the engineid somehow available through the already existing agentx connection?
[2008/08/27 07:15:58] #net-snmp <rstory> new session..
[2008/08/27 07:16:17] #net-snmp <splitbrain> okay. thanks for your help
--> mike_irc has joined #net-snmp
[2008/08/27 07:48:28] #net-snmp <EvalBMS> yo
[2008/08/27 07:48:41] #net-snmp <EvalBMS> so I think what I want to do is going to require forking the table_iterator module
[2008/08/27 07:49:18] #net-snmp <EvalBMS> we need to be able to 'delegate' get_first_data_point and get_next_data_point as we need to do IPC calls to get table indexes
[2008/08/27 07:49:36] #net-snmp <EvalBMS> threads aren't really a good fit
[2008/08/27 07:50:17] #net-snmp <EvalBMS> trouble is, netsnmp_iterator_info does not save enough/the right context for us to do this
[2008/08/27 07:50:19] #net-snmp <EvalBMS> and why should it
[2008/08/27 07:50:34] #net-snmp <EvalBMS> iterators aren't specifically tied to a single SNMP request
[2008/08/27 07:50:50] #net-snmp <EvalBMS> the outer net-snmp agent event loop only groks the concept of 'delegation' on a request basis
[2008/08/27 07:51:24] #net-snmp <EvalBMS> I suppose, as everything runs in one thread, we could hang a linked list of requests off netsnmp_iterator_info
[2008/08/27 07:51:45] #net-snmp <EvalBMS> and then check to see if there are any delegated iterator ops (so we hack the continuations further down)
[2008/08/27 07:55:10] #net-snmp <rstory> maybe you should use a cache...
[2008/08/27 07:56:47] #net-snmp <rstory> do you get all the indexes at once from the ipc?
[2008/08/27 07:57:07] #net-snmp <EvalBMS> nope
[2008/08/27 07:57:31] #net-snmp <EvalBMS> and we need to fire off IPC calls to get the data for each column
[2008/08/27 07:57:53] #net-snmp <rstory> right, but you don't need to do that until you find the right index..
[2008/08/27 07:58:06] #net-snmp <EvalBMS> I had thought of caching the indexes, but we still have that problem that we end up blocking...
[2008/08/27 07:58:11] #net-snmp <EvalBMS> on the other hand
[2008/08/27 07:58:23] #net-snmp <EvalBMS> i'm not too familiar with how we could do this
[2008/08/27 07:58:37] #net-snmp <EvalBMS> say we added a handler further up for the oid of the table itself?
[2008/08/27 07:58:45] #net-snmp <EvalBMS> and trapped accesses to it
[2008/08/27 07:59:10] #net-snmp <EvalBMS> we could cache it there, yes? but then the problem is making the cache available to handlers (i.e. table_iterator) further down
[2008/08/27 07:59:12] #net-snmp <rstory> and delegated all requests while the cache was being built
[2008/08/27 07:59:40] #net-snmp <EvalBMS> right
[2008/08/27 07:59:52] #net-snmp <EvalBMS> that is probably going to be more efficient than the other answers
[2008/08/27 08:00:03] #net-snmp <rstory> no, that's not hard.. you just stash it in the.. umm... agent request info... or something like that... can't remember the exact details..
[2008/08/27 08:00:30] #net-snmp <EvalBMS> I hadn't really considered it because I'm not confident about this concept of handler stacking, where tables are concerned
[2008/08/27 08:00:33] #net-snmp <rstory> whoops.. got a conference call.. be back in a bit.. maybe look at the baby steps handler.. i think it keeps info in the agent request struct..
[2008/08/27 08:00:48] #net-snmp <EvalBMS> I follow the code flow for stuff like serialize, read-only etc
[2008/08/27 08:00:54] #net-snmp <EvalBMS> no worries, thanks for the pointer!!
[2008/08/27 08:02:16] #net-snmp <EvalBMS> that would work for bgpPeerTable; but the routing table gives us something of a problem.
[2008/08/27 08:04:08] #net-snmp <rstory> it's netsnmp_agent_get_list_data
[2008/08/27 08:07:08] #net-snmp <EvalBMS> aha
[2008/08/27 08:07:30] #net-snmp <rstory> and netsnmp_agent_add_list_data.. see the row_merge and cache_handler helpers (agent/helpers/) for examples
[2008/08/27 08:08:00] #net-snmp <EvalBMS> so the get_first/get_next handlers can just peek at that given the reqinfo pointer.
[2008/08/27 08:08:54] #net-snmp <EvalBMS> oh wait, they don't get that
[2008/08/27 08:10:21] #net-snmp <EvalBMS> so I guess we need to extract it when the upper 'ipc cache' handler finally calls the next handler down
[2008/08/27 08:49:32] #net-snmp <EvalBMS> and stash it in the iterator info then
[2008/08/27 08:51:47] #net-snmp <EvalBMS> if you want a career in software, consider retaining the services of a psychiatrist
[2008/08/27 08:54:32] #net-snmp <EvalBMS> oh fiddlesticks
[2008/08/27 08:54:55] #net-snmp <EvalBMS> OID matches are most specific first, aren't they? there's no way to force our thing to be called
[2008/08/27 08:54:56] #net-snmp <EvalBMS> *unless*
[2008/08/27 08:55:58] #net-snmp <EvalBMS> we registered for the entire index space underneath
[2008/08/27 08:56:09] #net-snmp <EvalBMS> otherwise there is no guarantee our handler gets called
[2008/08/27 08:56:16] #net-snmp <EvalBMS> we always want it to get called first
[2008/08/27 09:12:52] #net-snmp <EvalBMS> hmmm...
[2008/08/27 09:22:44] #net-snmp <EvalBMS> ok I don't see a way of getting to netsnmp_agent_get_list_data() from within an iterator callback :(
[2008/08/27 09:22:59] #net-snmp <EvalBMS> our table iterator handler is never called until the helper handler has done its work
[2008/08/27 09:54:12] #net-snmp <EvalBMS> hmm, we could just put the data in the C++ class instance
[2008/08/27 09:54:36] #net-snmp <EvalBMS> provided we expose 'this' to the thunked "cache handler" and to the thunked iterator callbacks.
[2008/08/27 09:54:49] #net-snmp <EvalBMS> so get_next_data_point() is thunked to a C++ member function
[2008/08/27 09:54:58] #net-snmp <EvalBMS> so it can get at any shared state in the BgpMibHandler class itself
--> shakespear has joined #net-snmp
[2008/08/27 10:54:32] #net-snmp <rstory> EvalBMS: inject your own handler higher up the chain
--> mike_irc has joined #net-snmp
--> frostburn has joined #net-snmp
[2008/08/27 14:37:57] #net-snmp <EvalBMS> rstory: thanks for all the hints. if we put the get_first/get_next_data_point callbacks in the C++ class itself, and track the row index cache as a data member there, no worries regarding the lack of the reqinfo pointer in those callbacks; we can just use 'this' provided we thunk the calls right.
[2008/08/27 14:39:49] #net-snmp <SurcouF> how can tell to my perl snmp agentx to read /var/agentx/master instead of /var/run/agentx
[2008/08/27 14:39:56] #net-snmp <SurcouF> MIBDIRS=+mibs/ MIBS="+MYSQL-MIB" ./mysql-snmpd.pl
[2008/08/27 14:39:58] #net-snmp <SurcouF> /etc/snmp/mysqlsnmp.conf: line 1: Warning: Unknown token: agentXSocket.
[2008/08/27 14:40:06] #net-snmp <SurcouF> Warning: Failed to connect to the agentx master agent (/var/run/agentx): Unknown host (/var/run/agentx) (No such file or directory)
--> hardaker has joined #net-snmp
[2008/08/27 15:12:35] #net-snmp <SurcouF> hi hardaker
[2008/08/27 15:13:43] #net-snmp <hardaker> :-)
[2008/08/27 15:14:32] #net-snmp <SurcouF> how can I tell to my perl snmp agentx to read /var/agentx/master instead of /var/run/agentx ?
[2008/08/27 15:15:06] #net-snmp <hardaker> that should be the default...
[2008/08/27 15:15:25] #net-snmp <SurcouF> yes
[2008/08/27 15:15:44] #net-snmp <SurcouF> but debian/ubuntu packages have set agentx socket to /var/run/agentx
[2008/08/27 15:16:03] #net-snmp <hardaker> bad them...
[2008/08/27 15:16:09] #net-snmp <hardaker> file a bug report on that one.
[2008/08/27 15:16:29] #net-snmp <hardaker> (fedora did that for a while too until I convienced them it was evil because the *standard* dictated the other spot)
[2008/08/27 15:16:54] #net-snmp <SurcouF> * Moved the agentx socket from /var/agentx/master to /var/run/agents
[2008/08/27 15:16:54] #net-snmp <SurcouF> for FHS compatibility (closes:120015).
[2008/08/27 15:17:12] #net-snmp <SurcouF> yes
[2008/08/27 15:17:25] #net-snmp <SurcouF> but, why the directive agentxsocket is ignored ?
[2008/08/27 15:17:49] #net-snmp <hardaker> it should work.
[2008/08/27 15:17:52] #net-snmp <hardaker> what file are you putting it in?
[2008/08/27 15:18:31] #net-snmp <hardaker> (what .conf file)
[2008/08/27 15:18:38] #net-snmp <SurcouF> I've try /etc/snmp/perl.conf, /etc/snmp/mysqlsnmp.conf (using SNMP::init_mib to rename it)
[2008/08/27 15:18:53] #net-snmp <SurcouF> # MIBDIRS=+mibs/ MIBS="+MYSQL-MIB" ./mysql-snmpd.pl
[2008/08/27 15:18:55] #net-snmp <SurcouF> /etc/snmp/mysqlsnmp.conf: line 1: Warning: Unknown token: agentxsocket.
[2008/08/27 15:18:58] #net-snmp <hardaker> it should be in the one that init_snmp is pointing at.
[2008/08/27 15:19:29] #net-snmp <SurcouF> s/init_mib/init_snmp/
[2008/08/27 15:19:35] #net-snmp <SurcouF> # grep init_snmp mysql-snmpd.pl
[2008/08/27 15:19:36] #net-snmp <SurcouF> SNMP::init_snmp("mysqlsnmp");
[2008/08/27 15:21:04] #net-snmp <hardaker> you might try Ports => /var/agentx/master
[2008/08/27 15:22:02] #net-snmp <SurcouF> /etc/snmp/mysqlsnmp.conf: line 1: Warning: Unknown token: Ports.
[2008/08/27 15:24:08] #net-snmp <hardaker> sorry...
[2008/08/27 15:24:12] #net-snmp <hardaker> in the new() consturctor
[2008/08/27 15:25:51] #net-snmp <SurcouF> ok
[2008/08/27 15:26:02] #net-snmp <hardaker> (I didn't test it, mind you, but it should work?)
[2008/08/27 15:26:23] #net-snmp <SurcouF> not work
[2008/08/27 15:26:46] #net-snmp <SurcouF> Warning: Failed to connect to the agentx master agent (/var/run/agentx): Unknown host (/var/run/agentx) (No such file or directory)
[2008/08/27 15:26:53] #net-snmp <SurcouF> still have this message
[2008/08/27 15:27:05] #net-snmp <hardaker> mkdir /var/agentx
[2008/08/27 15:27:08] #net-snmp <hardaker> cd /var/agentx
[2008/08/27 15:27:19] #net-snmp <SurcouF> # ls -l /var/agentx/
[2008/08/27 15:27:19] #net-snmp <SurcouF> total 0
[2008/08/27 15:27:19] #net-snmp <SurcouF> srwxr-xr-x 1 root root 0 2008-08-27 23:51 master
[2008/08/27 15:27:31] #net-snmp <SurcouF> snmpd have already create it
[2008/08/27 15:27:47] #net-snmp <hardaker> ln -s /var/run/agents /var/agentx/master
[2008/08/27 15:27:48] #net-snmp <hardaker> heh.
[2008/08/27 15:29:06] #net-snmp <SurcouF> that weird
[2008/08/27 15:29:13] #net-snmp <SurcouF> but
[2008/08/27 15:29:14] #net-snmp <SurcouF> NET-SNMP version 5.2.3 AgentX subagent connected
[2008/08/27 15:29:16] #net-snmp <SurcouF> works
[2008/08/27 15:30:48] #net-snmp <SurcouF> and snmpwalk too
[2008/08/27 15:30:53] #net-snmp <SurcouF> well
[2008/08/27 15:34:44] #net-snmp <SurcouF> hardaker, thanks
[2008/08/27 15:34:57] #net-snmp <hardaker> glad it works.
[2008/08/27 15:35:34] #net-snmp <SurcouF> humm
[2008/08/27 15:35:47] #net-snmp <SurcouF> I think Debian patch is false
[2008/08/27 15:36:39] #net-snmp <SurcouF> another etch
[2008/08/27 15:36:40] #net-snmp <SurcouF> unix 2 [ ACC ] STREAM LISTENING 816049 9278/snmpd /var/agentx/master
[2008/08/27 15:36:49] #net-snmp <SurcouF> listenning on /var/agentx/master
[2008/08/27 15:39:27] #net-snmp <hardaker> I'm confused.
[2008/08/27 15:39:40] #net-snmp <hardaker> you mean it was listening by default on /var/agentx/master?
[2008/08/27 15:39:58] #net-snmp <hardaker> really there are two things: the snmpd and where it listens
[2008/08/27 15:40:03] #net-snmp <hardaker> and the perl module and where it connects
[2008/08/27 15:46:15] #net-snmp <SurcouF> yes
[2008/08/27 15:46:28] #net-snmp <SurcouF> but SNMP module try to connect to /var/run/agentx...
[2008/08/27 15:46:43] #net-snmp <hardaker> so they have one patch it sounds like that tries for the wrong place.
[2008/08/27 15:47:03] #net-snmp <SurcouF> yep
[2008/08/27 15:47:24] #net-snmp <SurcouF> I'll looking debian package sources
[2008/08/27 15:49:34] #net-snmp <SurcouF> -#define AGENTX_SOCKET "/var/agentx/master"
[2008/08/27 15:49:34] #net-snmp <SurcouF> +#define AGENTX_SOCKET "/var/run/agentx"
[2008/08/27 15:49:44] #net-snmp <SurcouF> in debian/patches/09_agentxpath.patch
[2008/08/27 15:49:53] #net-snmp <SurcouF> net-snmp-5.1.2/agent/mibgroup/agentx/protocol.h
[2008/08/27 15:51:30] #net-snmp <hardaker> I actually filed a bug report with them...
[2008/08/27 15:51:31] #net-snmp <hardaker> btw.
[2008/08/27 15:53:18] #net-snmp <SurcouF> ok
--> SurcouF has joined #net-snmp
--> frostburn2 has joined #net-snmp
--> hardaker has joined #net-snmp
--> SurcouF has joined #net-snmp
--> SurcouF has joined #net-snmp
--> SurcouF has joined #net-snmp
--> clever has joined #net-snmp
--> SurcouF has joined #net-snmp
--> SurcouF has joined #net-snmp
--> c_varun has joined #net-snmp
--> jsafrane has joined #net-snmp
--> snmpbot has joined #net-snmp