net-snmp-coders — Discussion of internal project coding (Please use this OR -users, NOT both!)

Re: 4.2 agent core dump on 64 bits Solaris

[Anders E. <an...@ba...>]

This is another tiny 64 bits patch for solaris2

It looks like the "lbolt" value is a 32 bit variable?

-- 
an...@ba...

Index: snmplib/system.c
===================================================================
RCS file: /f/CVSROOT/drift/ucd-snmp/snmplib/system.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- snmplib/system.c    2000/12/11 14:22:46     1.1
+++ snmplib/system.c    2000/12/13 15:22:28     1.2
@@ -500,7 +500,7 @@
            if (kid != -1) {
                named = kstat_data_lookup(ks, "lbolt");
                if (named) {
-                   lbolt = named->value.ul;
+                   lbolt = named->value.ui32;
                }
            }
        }

Re: snmpconf and the man pages

[Wes H. <har...@us...>]

>>>>> On Wed, 13 Dec 2000 16:06:41 +0100, Jerome Jargot <Jer...@fe...> said:

Jerome> It seems that the file 'snmpconf.1' has been forgotten in the
Jerome> file man/Makefile.

>> grep snmpconf man/Makefile
Jerome> (not found)

whoops.  Thanks.

-- 
Wes Hardaker
Please mail all replies to net...@li...

snmpconf and the man pages

[Jerome J. <Jer...@fe...>]

   Hello,

It seems that the file 'snmpconf.1' has been forgotten in the file
man/Makefile.

  > grep snmpconf man/Makefile
(not found)


that's all 

  Jerome

Re: IPX support

[Mark H. W. <mh...@am...>]

At work I applied the patch to the released 4.2, and was able to snmpwalk
both a JetDirect print server and a Netware 4.11 file server via IPX.  The
JetDirect is adjacent, and the file server is several hops away.

We've just had a request for some way to notify our student consultants
when paper is out, toner low, jammed, etc.  That can be done with
JetAdmin, but we really don't want to put that many knobs and switches in
front of the consultants.  I've suggested building a central monitoring
and notification gadget, and having IPX added to Net-SNMP makes this a lot
easier.

-- 
Mark H. Wood, radical centrist     OpenPGP ID 876A8B75     mh...@am...
Why is it that, of all the species on Earth, only the presence of Man
is considered an intrusion?

Sharing Trapd data [Enhancing snmptrapd]

[Brian A. W. <we...@op...>]

Hi All,

	I would like to get some feedback from the current developers on this list
about the best way to approach enhancing the trap daemon so that it can
better share trap data. Currently the only form of data sharing is done by
either reading the syslog files where snmptrapd currently writes log
information, or by using snmptrapd.conf for invoking additional programs to
process trap data. Before I get into why neither of those method are really
good solutions for what I'm trying to accomplish let me explain what I need
and the enhancement ideas that I have. [BTW, If I've missed a method please
let me know.]

	I'm one of the project members of the OpenNMS team (http://www.opennms.org)
and part of the project involves processing SNMP traps received from hosts
and transforming those traps into events within our system. Our main
development platform is Linux, but since the bulk (99%) of the code is
written in Java it can be ported to other platforms with of an effort than
C/C++, at least that it the theory.

	As part of the project developement I actually wrote a functional SNMP
library using 100% Java (http://www.opennms.org/files/releases/joeSNMP/). As
anyone who has actually written and used Java will know, the Java Virtual
Machine (JVM) is a PIG when it comes to resource utilization, especially
memory. On Linux/Unix there are additional issues that come up when trying
to use Java to write a daemon like trapd. The JVM must be run as root so
that it can access port 162 on the host and there is no inherient support
for changing the user/group identifiers after gaining access to 162. The
large resource utilization, combined with the root privialige requirement,
is going to be a big barrier to acceptance for a Java trap daemon.
Additionaly, due to the fact that only one process may open a specific IP
port within it's "namespace" (UDP or TCP), there can only be one trapd
process running at any given instance that has access to port 162.

	I have an idea to for getting around the issue and I would like feedback
from the group on the implementation. The idea in a nutshell is to modify
the net-snmp codebase so that the raw received SNMP packet could be kept as
an additional field within the PDU. This behavior would be controlled by a
flag of the SNMP session so that the additional memory would not be used if
the packet was not requested.

	The trap daemon could then set the flag and forward the raw information to
any additional processes on the system using some form of IPC like shared
memory, unix domain sockets, message queues, etc al. In addition to the raw
packet the address information (pdu->from) would be prepended to the packet
so the receiver would know the sender's address.

	If the code was modified in the described fashion then I could easily add
support within joeSNMP to interface with the changed net-snmp daemon. This
allows current users of net-snmp to keep any configuration investment,
minimizes the memory footprint when the OpenNMS daemons are not running, and
aleviates the need to run a JVM as root on linux. Additionally, it provides
ways for others to gain access to raw trap information without having to
write a trap daemon of their own.

	One last change that I would be interested in adding and would like
feedback on. What about adding support to the snmptrapd so that after it has
access to port 162 it could change its real & effective user/group id to a
non-root owner. This would keep the damage isolated should the daemon ever
be hacked. I've implemented this type of functionality in the OpenNMS icmpd
executable
(http://www.opennms.org/cgi-bin/cvsweb.cgi/icmpd/linux/src/main.c?rev=1.3&co
ntent-type=text/x-cvsweb-markup).

	Thanks

	Weave
	mailto:we...@op...

BTW: I've attached two context diffs to give an idea of what I was thinking.
Be warned, I have not tried to compile the changes yet!

Shared Libs LAST

[Jerome J. <Jer...@fe...>]

  

  Hello,




Dave Shield wrote:
> 
> > I know I may bother you Dave, but would you mind to tell me which
> > 'configurations choices' may affect 'libucdagent' ?
> 
>         $ cd ucd-snmp-4.2/agent
>         $ grep _MODULE *.c
>         agent_index.c:#ifdef USING_AGENTX_SUBAGENT_MODULE
>         agent_registry.c:#ifdef USING_AGENTX_SUBAGENT_MODULE
>                 :
>         $ grep mib_module *.c
>         agent_index.c:#include "mib_module_includes.h"
>         agent_read_config.c:#include "mib_module_includes.h"
> 
> So the AgentX mibgroup will affect these two files (as well as a
> number of the others that I've snipped).  The 'notification' mibgroup
> will affect the file agent_trap.c   The 'smux' mibgroup will affect
> the main snmpd.c file
>
>    In addition, anything importing the 'mib_module_xxx.h' files may
> possibly be affected, depending on exactly what's imported.
>

Could it be translate to :

   - 'libucdagent' can be shared between our master and our subagents ?

KNOWING that our master agent and all our subagents always use AgentX
protocol.





> 
> > >    The main configuration-specific library would be the 'libucdmibs'
> > > one.  This *will* be different depending on which modules are compiled in.
> >
> >
> > Why is it shared lib ?
> 
> 'Cos everything else is!
> 
> > Would it be better to modify the Makefile to let the two others library
> > shared but to make the agents link staticaly to the 'libucdmibs.a'
>
> Possibly - I'll pass on that one.  I've never been convinced of the
> need for it myself.
> 


May the 'Makefile.in' files be changed to allow my master agent and my
subagents to share the libs 'libsnmp.so', and 'libucdagent.so', but to
staticaly be linked to 'libucdmibs.a' ???



> > > What happens if you actually try to
> > > share the libraries in the way you've outlined?  Does it work, or not?
> >
> > It seems to work, but 'SEEMS' is not enough. That must be sure, because
> > we plan to change our admin using ucd-snmp. We are dealing with high
> > availability requierements, and the admin is concerned with these
> > requirements. Before our software go through our validation and test
> > process, I must check few things.
> 
> Well, the first thing is don't even *contemplate* using AgentX.
> This is still *EXPERIMENTAL* software.  It's probably more or less
> stable for most purposes, but if you need this sort of level of
> assurance, then the AgentX support is nowhere near ready yet.
> 
>    We can't really give you that sort of assurance in general anyway.
> But this particular feature is quite inappropriate for such an
> environment.   That's why it's clearly stamped "beta" code :-)
> I know of a number of situation where it will hang, and probably
> bring down the master agent as well.


I am not a native english speaker as you have surely noticed. High
availibility requierements apply on our sofware and harware part. But
the admin part has to be has stable has we want to.

Would you mind to tell me ALL these situations "where it will hang, and
probably bring down the master agent as well" ???


> 
>    (Note that I'm off for a few days very soon, so please keep all
> discussion on the lists.)
>
> Dave


OK


thanks very much again, Dave


         Jerome

Re: Timeout For ASYNC Call Backs.

[Daniel L. N. <dne...@jp...>]

Nevermind.  I found it session->timeout.  Interesting algorithm though. It
appears to only have timeouts in round seconds using the algorithm

timeout in seconds  = trunc((6*t+15)/1,000,000)

Any significance to the formula. Any reason why the algorithm allows
granularity of only seconds?

Thanks,
Daniel L. Needles


----- Original Message -----
From: Daniel L. Needles <dne...@jp...>
To: <net...@li...>
Sent: Monday, December 11, 2000 10:51 PM
Subject: Timeout For ASYNC Call Backs.


> Hello,
>   I'm trying to figure out where the timeout for a call back session is
set.
>
> Any ideas,
> Thanks,
> Daniel L. Needles
>

Timeout For ASYNC Call Backs.

[Daniel L. N. <dne...@jp...>]

Hello,
  I'm trying to figure out where the timeout for a call back session is set.

Any ideas,
Thanks,
Daniel L. Needles

Re: MIB.C Questions.

[<ni...@ba...>]

On Mon, 11 Dec 2000 17:55:33 -0800 "Daniel L. Needles" <dne...@jp...> wrote:

>   Thanks for the info.  I figured out using DS_SET_BOOLEAN() via
>snmp_out_toggle_options() how to return only values on the MIB.C functions.

OK

>Regarding returning the OID and OID INSTANCE separately, I think I can do it
>if I can find an equivallent sprintf for print_objid(). I found
>_sprint_objid()m but it is not a public function.

If you look a little further down, you should find sprint_objid, which consists
of just a call to _sprint_objid ....

/Niels


-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

Re: 4.2 agent core dump on 64 bits Solaris

[<ni...@ba...>]

On Mon, 11 Dec 2000 00:25:00 +0100 Anders Ellefsrud <an...@ba...> wrote:
>
>> >When compiling 4.2 on 64 bits solaris 8 and doing an snmpwalk, the
>> >agent fails [in dlmod]
>>
>> Yep, there is a stupid bug there, that uses an int where it should use a long.
>> Could you try the following patch, and tell me if it fixes the problem?
>> [...]
>
>Add this in addition to your patch, and it starts to work in my
>64 bits environment.

You are right, I overlooked those. Thanks, I will commit the complete patch to
the repositoty now.

/Niels


-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

how to start

[Someshwar P. <pa...@pa...>]

Dear all,

        i want to build SNMP agent for our system. so how should i =
start?  what i suppose to consider?

thanks in advance.
-som
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Someshwar  R.  Parate     <pa...@pa... >
                                         <pa...@pa...>

Office :=20
     3rd Fl., CHiPS Bldg.,  KAIST, =20
     373-1 Kusung-Dong, Yusung-Gu,
     TAEJON, 305-701, South Korea.
    =20
     Tel.  : +82-42-862-4613 ~ 7               =20
     Fax. : +82-42-862-4618
     Cellular : +82-19-472-2675
     Homepage: http://www.geocities.com/somesh_75/som.html

-------------------------------------------------------------

Re: MIB.C Questions.

[Daniel L. N. <dne...@jp...>]

Niels,
   Nevermind. I found the other sprintf function.

Thanks,
Daniel L. Needles

----- Original Message -----
From: Daniel L. Needles <dne...@jp...>
To: <ni...@ba...>; UCD CODERS <net...@li...>
Sent: Monday, December 11, 2000 5:55 PM
Subject: Re: MIB.C Questions.


> Niels,
>    Thanks for the info.  I figured out using DS_SET_BOOLEAN() via
> snmp_out_toggle_options() how to return only values on the MIB.C
functions.
>
> Regarding returning the OID and OID INSTANCE separately, I think I can do
it
> if I can find an equivallent sprintf for print_objid(). I found
> _sprint_objid()m but it is not a public function.
>
> Any ideas?
>
> Thanks,
> Daniel L. Needles
>

Re: MIB.C Questions.

[Daniel L. N. <dne...@jp...>]

Niels,
   Thanks for the info.  I figured out using DS_SET_BOOLEAN() via
snmp_out_toggle_options() how to return only values on the MIB.C functions.

Regarding returning the OID and OID INSTANCE separately, I think I can do it
if I can find an equivallent sprintf for print_objid(). I found
_sprint_objid()m but it is not a public function.

Any ideas?

Thanks,
Daniel L. Needles

Agentx subagent - master agent interaction

[Szaboky, G. (George) <sz...@lu...>]

Can someone explain the interaction between the master agent and subagent?
Here is the scenario. I have a master agent and subagent.

1. both start, the subagent registers for indices and then mib modules. I am
using TCP/IP port number 705 for transport. Ex: snmpd -C -c demo.conf -x
139.149.91.166:705. Life is wonderful.

2. after both have started, the master agent is restarted. How does the
subagent detect this? What re-registration should it go through? My agent is
on a Solaris box and the subagent is on a different box. When the master
agent is restarted, it fails to init because the tcp/ip socket is still in
use. If I check the connection with netstat, I find the connection is in the
FIN_WAIT_2 state. It's waiting for the subagent to close the connection. How
can subagent detect this and close it? I assume once it's closed, the master
agent can be restarted and the subagent will have open another session, get
indices and register for mibs again. The subagent code is just a modified
version of the example in the tutorial.

3. after both have started, the subagent is restarted. I appears that
subagent should keep it's indices and session id and unregister them and
then register them. Is this true? It appears that the master agent keeps the
session open and thus the socket up for sometime not allowing the restarted
subagent to reconnect. How is this cleared? 

With the API provided what are the logical steps that should be taken in
each scenario? I am currently playing around with agentx_send_ping() and
saving of indices and sessions IDs, but I have yet to get around scenario 2
or 3 with out restarting the master agent or the subagent or both. Do you
have any ideas?

Thanks in advance,

George

 

Re: MIB.C Questions.

[<ni...@ba...>]

On Mon, 11 Dec 2000 11:47:35 -0800 "Daniel L. Needles" <dne...@jp...> wrote:

> I''ve been looking over MIB.C trying to find individual functions to give:
>OID
>OID Instance
>OID Value Type
>OID Value
>
>So far I've found only 'collective' functions.  That is, print_objid returns
> both the OID and OID Instance together.  print_value returns both the OID
> Value Type and the OID value together (and in some cases just the OID value).
>
> The alternative is to build my own print functions.

There is no public exported functions for that per se. But the function
_get_symbol will return you the complete string, with a pointer to the split
between OID and instance, and returns a mib tree pointer where you can find the
type.

If you were more specific about what you want to get, I could be more specific
on how to get it.

> I'm trying to find where the snmp_pdu structure is defined but haven't found
> it yet.

It is in snmp_api.h

/Niels



-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su

RE: SNMP TRAP through AgentX sub-agent

[Jim P. <jpi...@ou...>]

I still am not able to send traps from my agentX sub-agent.

What I have found is that the thecallbacks[] table in callbacks.c is not
initialized with the major/minor number combos (1/7 and 1/6 ...
SNMP_CALLBACK_APPLICATION/SNMPD_CALLBACK_SEND_TRAP2 and
SNMP_CALLBACK_APPLICATION/SNMPD_CALLBACK_SEND_TRAP1).


When the sub-agent begins thecallbacks[] table in callbacks.c is initialized
with the following calls:
  snmp_register_callback (major=0, minor=3,  new_callback=0x806666c
<subagent_register_for_traps>, arg=0x80dbc88) at callback.c:49
  snmp_register_callback (major=0, minor=2,  new_callback=0x8066500
<subagent_shutdown>, arg=0x80dbc88) at callback.c:49
  snmp_register_callback (major=1, minor=1,  new_callback=0x8066490
<agentx_registration_callback>, arg=0x80dbc88) at callback.c:49
  snmp_register_callback (major=1, minor=2,  new_callback=0x8066490
<agentx_registration_callback>, arg=0x80dbc88) at callback.c:49      
  snmp_register_callback (major=1, minor=3,   new_callback=0x80664d0
<agentx_sysOR_callback>, arg=0x80dbc88) at callback.c:49   
  snmp_register_callback (major=1, minor=4,  new_callback=0x80664d0
<agentx_sysOR_callback>, arg=0x80dbc88) at callback.c:49 

Note that the major/minor number combos (1/7 and 1/6 ...
SNMP_CALLBACK_APPLICATION/SNMPD_CALLBACK_SEND_TRAP2 and
SNMP_CALLBACK_APPLICATION/SNMPD_CALLBACK_SEND_TRAP1) are never used as
arguments. The snmp_register_callback() function is never called again.

As a test my agentx code calls send_easy_trap(6, 3), which makes calls
through snmp_call_callbacks().
snmp_call_callbacks (major=1, minor=7, caller_arg=0x8126480) at
callback.c:83      
snmp_call_callbacks (major=1, minor=6, caller_arg=0x8126480) at
callback.c:83      

snmp_call_callbacks() does nothing as the major/minor number combos (1/7 and
1/6 ... SNMP_CALLBACK_APPLICATION/SNMPD_CALLBACK_SEND_TRAP2 and
SNMP_CALLBACK_APPLICATION/SNMPD_CALLBACK_SEND_TRAP1) are NOT in the
thecallbacks[] table, as expected.  Because of this, traps are NOT sent to
the master agent.

Is there anything my AgentX sub-agent needs to do in order to send traps,
such as read a configuration file directive or make a ds_set_boolean() call?
Should my sub-agent be calling something similar to init_snmpNotifyTable()?

Thanks.

jim
---
Jim Pickering                  Internet: mailto:jr...@ou...
OutBack Resource Group, Inc.   Voice: 805-542-8570 ext. 19
3450 Broad Street, Suite 103   FAX: 805-541-5467
San Luis Obispo, CA 93401      WWW: http://www.outbackinc.com/


> -----Original Message-----
> From: Wes Hardaker [mailto:wjh...@uc...]
> Sent: Friday, November 17, 2000 8:18 AM
> To: Dave Shield
> Cc: Wes Hardaker; Jim Pickering; 'Nuno Miguel Neves'; '3tcdgwg3';
> 'Michelle Xie'; net...@li...; Jerry Mendonca;
> Gary Baker; Jason Varley
> Subject: Re: SNMP TRAP through sub-agent
> 
> 
> >>>>> On Fri, 17 Nov 2000 10:11:49 +0000, Dave Shield 
> <D.T...@cs...> said:
> 
> Dave> Jargot's latest message has essentially pinpointed the memory
> Dave> problem, and I understand what's going wrong with SETs, so we
> Dave> should be able to get all of this into 4.2.pre2.
> 
> Excellent!
> 
> -- 
> Wes Hardaker
> TIS Labs
> Network Associates
> 

MIB.C Questions.

[Daniel L. N. <dne...@jp...>]

Hello,
 I''ve been looking over MIB.C trying to find individual functions to =
give:
OID
OID Instance
OID Value Type
OID Value

So far I've found only 'collective' functions.  That is, print_objid =
returns both the OID and OID Instance together.  print_value returns =
both the OID Value Type and the OID value together (and in some cases =
just the OID value).

The alternative is to build my own print functions. I'm trying to find =
where the snmp_pdu structure is defined but haven't found it yet.

Any ideas?
Thanks,
Daniel L. Needles

Re: Future Plans III - Agent

[Harrie H. <ha...@co...>]

Dave Shield wrote:
> 
> This is the third of three 'kite-flying' messages, floating some ideas
> regarding the future developments of the Net-SNMP suite.   This message
> concerns issues relating to the agent.   The accompanying messages cover
> the UCD MIB and library respectively.
> 
>    Please feel free to comment on any of these, or to add any other ideas
> that occur to you.   This is probably the best chance we'll ever have to
> regroup and plan for the future, and I'm keen that we make the most of it.
> 
>    MIB module API
>         The MIB module API was inherited from the original CMU
>         suite, and is occasionally proving restrictive.  Do we
>         wish to extend or replace it?

I beleive a more optimised API for the stub functions would be required.
For instance, an OID should be in a struct containing a OID array and an
int
for its length. Now these are always seperate. Similar things would be
possible for Varbinds.


>    Table handling
>         There is a start at simple cached table handling.  Do we
>         want to make more use of this?   One possible extension would
>         be support for "persistently indexed" tables, which are commonly
>         mentioned in MIBs, and conveniently ignored in implementations.
>         Could/Should the "complex table" routines be used instead?

This also has to do a lot with the stub functions for the MIB module
implementations.

> 
>    Existing modules
>         A start has been made at cleaning up these implementations,
>         to make them easier to follow and maintain.  Do we wish to
>         continue this, and start using these versions in earnest?
>         Do we wish to extend and update these existing modules?
>         (e.g. newer versions of the mib-2 routines)

I would like to see us building all MIB modules into a seperate library.
By building the complete set of MIB module in small libraries (per MIB
module)
I beleive the complete package becomes easier to use with respect to
third party use that would only have a small set of MIB modules besides
enterprise
specific MIB module implementations.

> 
>     MIBs and "internal" features
>         Certain "mib modules" actually implement internal features,
>         necessary for the correct operation of the agent.  (e.g.
>         VACM access control, notifications, AgentX).
>            How closely linked should the features and the corresponding
>         MIBs be?

I believe the MIB modules should be seperate libraries, but
for instance all SNMPv3 framework MIB module implementations should be
in 1 library.
Now VACM is in the mibII directory and the rest in the snmpv3-directory.
 
>     Agent file organisation
>         The organisation of the code files is somewhat arbitrary,
>         and is not always optimal.  Should we consider how routines
>         are grouped together - particularly with regard to embedded
>         subagent use.

I beleive this is an important point. I would like to have a
better/easier
approach of having the SNMP agent embedded in an other application.
For instace, I could did not have to use the snmpd.c file to have the
SNMP agent
embedded in the Apache HTTP server. However, I need to cut and past some
functions that were in snmpd.c and not in a library.

> 
>     Threading
>         The agent currently assumes a simple, single-threaded model.
>         Is it worth investigating a multi-threaded approach - e.g.
>         processing varbinds in parallel?

This would be usefull, however, it also depends a lot on the 
MIB module implementation. This should be done with care.

> 
>     Subagent APIs
>         The agent may need to co-exist with various other agents.
>         Is it worth investigating providing "subagent" connectivity
>         with (e.g.) Sun, Microsoft, SNMP Research, etc

I wonder if other vendors would give up that AgentX api.
Some provide also an API to AgentX (as standardized within the IETF)
So a sub agent of NET_SNMP could co-operate with those vendors
I guess.

Harrie

Re: Re: Shared Libs 2 -- SOS

[Jerome J. <Jer...@fe...>]

version  : ucd-snmp version 4.2
system   : SunOS 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-250
protocol : AgentX


   Hello,



Dave Shield wrote:
> 
> Of the three libraries produced, the 'libsnmp' library is common
> to both the agent and applications.  I don't believe that any changes
> to the set of agent modules configured in, should have any effect on
> the core library (apart perhaps from the list of MIB files loaded by
> default).

Find.

In the email:'Shared Libs 3 -- SOS' of the Coders mailling list ; I show
(I hope) where the little gap between libsnmp sizes comes from.


>    The 'libucdagent' library ought to be common between different
> configurations of the agent.  There are certain configuration choices
> that may affect this library, but not many.


I know I may bother you Dave, but would you mind to tell me which
'configurations choices' may affect 'libucdagent' ?


>    The main configuration-specific library would be the 'libucdmibs'
> one.  This *will* be different depending on which modules are compiled in.


Why is it shared lib ?
Would it be better to modify the Makefile to let the two others library
shared but to make the agents link staticaly to the 'libucdmibs.a'


> It should in general be safe to share 'libucdagent' between subagents.
> It should definitely be safe to share 'libsnmp' between subagents.
> It would not in general be safe to share 'libucdmibs' between subagents.

That's cool to have your word on it.


> Sorry I haven't had a chance to investiage what causes the (minor) size
> differences between the libraries.


See what I have found in the email:'Shared Libs 3 -- SOS' of the Coders
mailling list


> What happens if you actually try to
> share the libraries in the way you've outlined?  Does it work, or not?

It seems to work, but 'SEEMS' is not enough. That must be sure, because
we plan to change our admin using ucd-snmp. We are dealing with high
availability requierements, and the admin is concerned with these
requirements. Before our software go through our validation and test
process, I must check few things.


  Thanks very much Dave


    Jerome

Re: Future Plans II - Library

[Dave S. <D.T...@cs...>]

>             For instance, if you push the actual select() loop into the 
> library, that would be a Bad Thing because it makes it hard to integrate the 
> library with other software that may have its own select() loops.

Indeed.
<wide eyed and innocent>
Did I suggest anything else.
</wide eyed and innocent>
 

>   Okay, so what would happen if the SNMP library was doing the select()?  
> Well in theory you could use the same approach as above, but in reverse:

That's what I was thinking, yes.

>                                           But this is actually a problem 
> because there may not be any way to request that information from the 
> third-party library

OK - so this means that the select_info_plus routine mustn't be the *only*
way to achieve this requirement.

   But you could always have two parallel selects in the main application.
Sort-of like the agent does at the moment.

   Alternatively, if we provided access to the lower-level lists of fd's and
callbacks, then the "awkward" applications could set things up themselves,
in the way you've described, and the "simple" applications could use the
higher-level routine to take care of things for them.
   I'm a great believer in simplifying the common cases - but that doesn't
necessarily mean preventing those that need to get their hands dirty from
doing so.


Anyway - I'll leave you lot to ponder over the various cans of worms I've
opened.   It's five to five  (it's Friday, and it's craaackeerjaaack!!!
oops, sorry - wrong decade!) and I hear a train a-calling me.....


Dave

Re: Shared Libs 2 -- SOS

[Dave S. <D.T...@cs...>]

> I know I may bother you Dave, but would you mind to tell me which
> 'configurations choices' may affect 'libucdagent' ?


	$ cd ucd-snmp-4.2/agent
	$ grep _MODULE *.c
	agent_index.c:#ifdef USING_AGENTX_SUBAGENT_MODULE
	agent_registry.c:#ifdef USING_AGENTX_SUBAGENT_MODULE
		:
	$ grep mib_module *.c
	agent_index.c:#include "mib_module_includes.h"
	agent_read_config.c:#include "mib_module_includes.h"


So the AgentX mibgroup will affect these two files (as well as a
number of the others that I've snipped).  The 'notification' mibgroup
will affect the file agent_trap.c   The 'smux' mibgroup will affect 
the main snmpd.c file

   In addition, anything importing the 'mib_module_xxx.h' files may
possibly be affected, depending on exactly what's imported.



> >    The main configuration-specific library would be the 'libucdmibs'
> > one.  This *will* be different depending on which modules are compiled in.
> 
> 
> Why is it shared lib ?

'Cos everything else is!

> Would it be better to modify the Makefile to let the two others library
> shared but to make the agents link staticaly to the 'libucdmibs.a'

Possibly - I'll pass on that one.  I've never been convinced of the
need for it myself.



> See what I have found in the email:'Shared Libs 3 -- SOS' of the Coders
> mailling list

Already replied.


> > What happens if you actually try to
> > share the libraries in the way you've outlined?  Does it work, or not?
> 
> It seems to work, but 'SEEMS' is not enough. That must be sure, because
> we plan to change our admin using ucd-snmp. We are dealing with high
> availability requierements, and the admin is concerned with these
> requirements. Before our software go through our validation and test
> process, I must check few things.

Well, the first thing is don't even *contemplate* using AgentX.
This is still *EXPERIMENTAL* software.  It's probably more or less
stable for most purposes, but if you need this sort of level of
assurance, then the AgentX support is nowhere near ready yet.

   We can't really give you that sort of assurance in general anyway.
But this particular feature is quite inappropriate for such an
environment.   That's why it's clearly stamped "beta" code :-)
I know of a number of situation where it will hang, and probably
bring down the master agent as well.

   (Note that I'm off for a few days very soon, so please keep all
discussion on the lists.)


Dave

Re: Shared Libs 3 -- SOS

[Dave S. <D.T...@cs...>]

> So, the 20b between the libsnmp-0.4.2.so generated comes from the
> definition of DEFAULT_MIBS in config.h.
> 
> 
> Wes already told me that it should be OK, but knowing these new details
> ; 
> Would you mind to ensure me that the 'libsnmp-0.4.2.so' generated for an
> agent can be used by another ?

Yes.
The only effect of this difference is to control which MIB object names will
be interpreted by default by the relevant applications.  In this case,
one library will recognise the Host-Resources-MIB descriptors, and the
other will recognise the VACM-MIB descriptors.

Other than that, the functionality will be identical.

Dave

Re: Future Plans II - Library

[John N. <jb...@ca...>]

> The loop would naturally be somewhere else in the application, yes. But it
> might be useful to have a bundled call that is essentially a super-charged
> 'select'.   In other words, an extended form of 'snmp_select_info'.
> 
> >  .... (in fact this is exactly what the agent does).
> 
> Exactly - the *agent* does it, not the library.  So it's not available to
> any other application.
> 
> > So I think essentially what I am saying is that the functionality is
> > already there.
> 
> But in the wrong place :-)
> 
> [ Note that this isn't the first time I've pushed agent handling back into
>   the library.   Compare the main body of the v3 and v4 agent :-)  ]

  I think I see what you mean now.  But this needs to be thought out very 
carefully.  For instance, if you push the actual select() loop into the 
library, that would be a Bad Thing because it makes it hard to integrate the 
library with other software that may have its own select() loops.  As an 
example, I recently wrote some GTk applications that also used the Net-SNMP 
library.  The body of such an application calls a function gtk_main() that 
never returns; all processing takes place in callback functions.  Underlying 
this is some type of event loop (this is going to be true of most windowing 
systems).  My approach was to use snmp_select_info to discover what fds I 
wanted callbacks on (in addition to the callbacks I was getting for window 
events) and request those callbacks from the GTk main loop, and in those 
callbacks just call the SNMP processing routines.  No problem.

  Okay, so what would happen if the SNMP library was doing the select()?  
Well in theory you could use the same approach as above, but in reverse:  I 
could ask the GTk toolkit what things it would like me to select() on, and 
then add those to the SNMP library's select via the "extended 
snmp_select_info" call.  Fair enough.  But this is actually a problem 
because there may not be any way to request that information from the 
third-party library (I don't know if you can or not with GTk specifically).  
Or the desired event loop might be more complex than a simple select (I'm 
thinking Win32 here really -- Glib/GTk jump through *lots* of hoops there 
that we would rather not know about: but you would have to if you want to do 
this reversed scenario).

  I'm not against moving agent stuff into the library!  I'm just quite sure 
there are things that really DO belong JUST in the agent.

> >   FWIW, the multi-transport stuff I did basically adds an API call which
> > effectively says "here's a socket (of some type), please do SNMP on it".
> 	[snip]
> >  Is this more what you were getting at?
> 
> Precisely.   I haven't had a chance to look over your code yet,
> but it sounds to be *exactly* the sort of thing I'm on about.
> 
> I'm away for a few days now, but I hope to take a printout of the
> library code with me, and try and dissect snmp_api.c into more
> manageable chunks.

  Have a good break!

John
-- 
// Dr. John Naylon // Senior Software Engineer // Cambridge Broadband Ltd.
// The future of broadband wireless access  // www.cambridgebroadband.com

Re: Future Plans - testing

[Dave S. <D.T...@cs...>]

> I'm in favor of establishing a framework that embraces change,
> and ensures that desirable functionality is retained.
> This would include external testing to start, but eventually unit tests
> can be developed to ensure that each module keeps its interface
> agreements.

Sounds good.
Ideally, I'd like each file to include an integral test suite.
Something like the code at the end of agent/agent_registry.c

Or it might be more appropriate to use the external 'testing'
tree - though that might be harder to keep in synch.
(Well, not harder exactly - need more discipline from the coders :-) )


> I think that using a tester, like the SilverCreek one you've seen me
> discuss recently, is a real important tool to validate that the agent,
> as it changes shape, honors the protocol and supports its MIBs
> correctly.

I haven't had a chance to review these reports in detail.
But I'd agree that this sort of validation is extremely useful.

I'd also welcome a repository of the config.h & snmpwalk output
from various architectures, that you and Niels have been providing
recently.


  This project is growing up fast, and we need to be ready for the
effects of this! 

Dave

Re: Moving ucd-snmp -> net-snmp

[Dave S. <D.T...@cs...>]

> How will changes we make tomorrow affect existing installations ?

In general, I'd hope that any changes will have as minimal impact as
possible.   Certainly, we should aim to retain backwards compatibility
wherever possible - either directly or via wrapper routines.

> I'm a little concerned that the name change is going to create
> additional confusion for developers and installers :

There's likely to be some potential confusion - certainly.
That's partly why I was lobbying to release 4.2 as 'ucd-snmp'
rather than 'net-snmp'.   My personal belief is that patches
should also be 'ucd-snmp-4.2.1', and that the net-snmp name should
be reserved for the next "full" release, which may include some
more significant changes.   (As per my other postings).


   You raise some very pertinent questions, which we need to
address before the next (net-snmp) release.
My gut reactions are as follows:


> 1) Whose libsnmp.a, libxxmib.a is that anyway ?  CMU ? UCD ? net-snmp ?

The snmp library should be interface compatible with the ucd ones,
so we could install it as 'libsnmp' if we wished.
   Perhaps it would be more polite to install it as 'libnetsnmp' and
have an optional link as 'libsnmp' ?

   The agent library (which needs a cleaner interface IMHO) should
become 'libnetagent', or possibly 'libsnmpd'.    I've never been
convinced of the point of 'lib{ucd,net}mibs' anyway.   We'd be better
off improving the support for dynamic loading of mib modules.


>    And, include file location: is it /usr/include/ucd-snmp 

We probably ought to move towards {PREFIX}/include/net-snmp,
but again, perhaps with a compatibility link for ucd-snmp.


> 2) Does the agent use /var/net-snmp for engineBoots, etc. ?

I presume so, yes.


> 3) Should we reduce the number of places to look for configuration data
> ?
>    /etc/snmp ?  /var/ucd-snmp ? /usr/local/share/snmp ?

Well, there's typically only three - the 'standard' PREFIX/share/snmp,
the 'persistent' /var/{ucd,net}-snmp, and the personal ~/.snmp

  Confusion between (e.g.) /etc and /usr/local/share is down to
differences between how the suite is configured.   Short of removing this
facility (which is likely to be unpopular!), I don't see any way around this/

> 4) Do we change UCD-SNMP-MIB.txt to NET-SNMP-MIB.txt ?
>    There are six sets of (.txt, .inc) MIB files affected.

Yes.   Though I'd hope we'd also take the opportunity to update and
improve the MIB structure (see Future Plans I - MIB)


> It is good that 4.2 is released, and no major changes are in the works
> just yet.   The external view of the project direction should be clear
> to sys-admin users and vendors that currently re-package UCD-SNMP, as
> well as new users and seasoned developers.

I'd like us to support 4.2 in a stable format - perhaps for the next
six to twelve months.   At the same time, we would be working towards
releasing a "new improved" net-snmp release (5.0?).
   As with the v3/v4 move, I'd envisage some period of overlap, during
which those who wanted a stable, reliable (but ultimately dead-end)
environment could stick with 4.2, while those wishing to follow the
active development path, could switch to 5.0.

  As a *very* strawman timetable - I'd propose targets along the following
lines:

	Q1 2001		design and development of 5.0 structure
	April 2001	first release of 5.0 - *experimental alpha*
	Q2 2001		implementation experience fixes & development
	July 2001	second release of 5.1 - *stable beta*
			freezing of 4.2 line development
	end 2001	release of 5.2 - full, stable version
			withdrawal of 4.2

Obviously, release numbers and target dates are simply placeholders.
But that sort of program should balance the need for a stable package.
without committing us to supporting old code indefinitely.

Comments?


Dave