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

Re: Future Plans II - Library

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

> > Currently, yes.   What I'm asking is whether we could/should consider
> > moving [{read...}fd flexibility] within the library - maybe not in
> > this precise form, but something with the same general effect.

>   What I was getting at is that there aren't really any long-running select()
> loops in the library, which is when you'd want this register_fd type of
> functionality.  It seems that the more natural way to use the library is to
> have an external select() loop somewhere else in the application,

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 :-)  ]



>   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.

Dave

Re: Shared Libs 2 -- SOS

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

> Would you mind to tell me what is wrong in the following:
	[snip]
> Thus the shared libs produced by ucd-snmp are agent/mibs specific.

This :-)

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).

   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.

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

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.

Sorry I haven't had a chance to investiage what causes the (minor) size
differences between the libraries.  What happens if you actually try to
share the libraries in the way you've outlined?  Does it work, or not?


Dave

hrSWRun

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

Both 4.1.2 and 4.2 fails to return the complete list of
processes in hrSWRun from time to time as the following
test-program shows.

/tmp/testps:

#!/local/bin/perl
# Anders Ellefsrud, BaseFarm 2000-12-06 <an...@ba...>

use SNMP;

our $host = $ARGV[0];
die "Usage: $0 host\n" unless $host;

$cmty = 'public';

SNMP::addMibDirs ('/local/snmp/share/snmp/mibs');

our $s = new SNMP::Session(DestHost=>$host, Community=>$cmty);

our $idx_varb = new SNMP::VarList(['hrSWRunIndex']);

our (@pid);

while (1) {
        my $pid = $s->getnext ($idx_varb);
        last if $idx_varb->[0]->tag ne 'hrSWRunIndex';
        print "$pid ";
        push (@pid, $pid);
}
print ":$#pid\n";

exit 1 if $#pid < 130;	# Adjust to fit

#!/bin/sh
while /tmp/testps  localhost ; do : ;done

When run against an solaris8 host, it fails to produce the
complete process-list fairly often when tried against a busy
host, and most often when talking to "localhost" (probably due
to speed?). My idea is that this happens when it tries to fetch
information for a process which has exit'ed after the pid was
added to the proc_table[], but before the var_hrswrun() tries to
dig into the process-data. It looks like the processing of the table
stops when it hits such an non-process, instead of just ignoring it
and carrying on with the next one?

I have tried to apply the following patch which _appears_ to
fix this problem. If it introduces something else, I do not
know..., it is probably not even the correct fix. But it
appears to remove the symptoms.

I have only looked into the #if _SLASH_PROC_METHOD_
part of the code, the same problem might be present
in other parts? (read: probably is).

-- 
Regards,

Anders Ellefsrud
an...@ba...

Index: agent/mibgroup/host/hr_swrun.c
===================================================================
RCS file: /f/CVSROOT/drift/ucd-snmp/agent/mibgroup/host/hr_swrun.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 hr_swrun.c
*** agent/mibgroup/host/hr_swrun.c	2000/12/11 14:22:42	1.1.1.1
--- agent/mibgroup/host/hr_swrun.c	2000/12/11 14:55:34
***************
*** 279,285 ****
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
      static psinfo_t psinfo;
!     static psinfo_t *proc_buf = &psinfo;
      int procfd;
      char procfn[sizeof "/proc/00000/psinfo"];
  #else
--- 279,285 ----
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
      static psinfo_t psinfo;
!     static psinfo_t *proc_buf;
      int procfd;
      char procfn[sizeof "/proc/00000/psinfo"];
  #else
***************
*** 321,330 ****
      }
      if (oldpid != pid || proc_buf == NULL) {
  #if _SLASH_PROC_METHOD_
  	sprintf(procfn, "/proc/%.5d/psinfo", pid);
! 	if ((procfd = open(procfn, O_RDONLY)) == -1) return NULL;
! 	if (read(procfd, proc_buf, sizeof(*proc_buf)) != sizeof(*proc_buf)) abort();
! 	close(procfd);
  #else
  	if (kd == NULL) return NULL;
  	if ((proc_buf = kvm_getproc(kd, pid)) == NULL) return NULL;
--- 321,333 ----
      }
      if (oldpid != pid || proc_buf == NULL) {
  #if _SLASH_PROC_METHOD_
+ 	proc_buf = &psinfo;
  	sprintf(procfn, "/proc/%.5d/psinfo", pid);
! 	if ((procfd = open(procfn, O_RDONLY)) != -1) {
! 		if (read(procfd, proc_buf, sizeof(*proc_buf)) != sizeof(*proc_buf)) 
abort();
! 		close(procfd);
! 	} else
! 		proc_buf = NULL;
  #else
  	if (kd == NULL) return NULL;
  	if ((proc_buf = kvm_getproc(kd, pid)) == NULL) return NULL;
***************
*** 340,347 ****
  		return NULL;
  #else
  	    long_return = 1;		/* Probably! */
- #endif
  	    return (u_char *)&long_return;
  
  	case HRSWRUN_INDEX:
  	    long_return = pid;
--- 343,350 ----
  		return NULL;
  #else
  	    long_return = 1;		/* Probably! */
  	    return (u_char *)&long_return;
+ #endif
  
  	case HRSWRUN_INDEX:
  	    long_return = pid;
***************
*** 354,360 ****
  		*cp = '\0';
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    strcpy(string, proc_buf->pr_fname);
  #else
  	    strcpy(string, proc_buf->p_user.u_comm);
  #endif
--- 357,366 ----
  		*cp = '\0';
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    if (proc_buf)
! 		    strcpy(string, proc_buf->pr_fname);
! 	    else
! 		    strcpy(string, "<exited>");
  #else
  	    strcpy(string, proc_buf->p_user.u_comm);
  #endif
***************
*** 398,404 ****
  		*cp = '\0';
  #elif defined(solaris2)
  #ifdef _SLASH_PROC_METHOD_
! 	    strcpy(string, proc_buf->pr_psargs);
  	    cp = strchr(string, ' ');
  	    if (cp) *cp = 0;
  #else
--- 404,413 ----
  		*cp = '\0';
  #elif defined(solaris2)
  #ifdef _SLASH_PROC_METHOD_
! 	    if (proc_buf)
! 	        strcpy(string, proc_buf->pr_psargs);
! 	    else
! 		sprintf(string, "<exited>");
  	    cp = strchr(string, ' ');
  	    if (cp) *cp = 0;
  #else
***************
*** 448,456 ****
  		string[0] = '\0';
  #elif defined(solaris2)
  #ifdef _SLASH_PROC_METHOD_
! 	    cp = strchr(proc_buf->pr_psargs, ' ');
! 	    if (cp) strcpy(string, cp+1);
! 	    else string[0] = 0;
  #else
  	    cp = proc_buf->p_user.u_psargs;
  	    while (*cp && *cp != ' ') cp++;
--- 457,468 ----
  		string[0] = '\0';
  #elif defined(solaris2)
  #ifdef _SLASH_PROC_METHOD_
! 	    if (proc_buf) {
! 	        cp = strchr(proc_buf->pr_psargs, ' ');
! 	        if (cp) strcpy(string, cp+1);
! 	        else string[0] = 0;
! 	    } else
! 		string[0] = 0;
  #else
  	    cp = proc_buf->p_user.u_psargs;
  	    while (*cp && *cp != ' ') cp++;
***************
*** 534,540 ****
  	    switch ( proc_table[LowProcIndex].kp_proc.p_stat ) {
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    switch (proc_buf->pr_lwp.pr_state) {
  #else
  	    switch ( proc_buf->p_stat ) {
  #endif
--- 546,552 ----
  	    switch ( proc_table[LowProcIndex].kp_proc.p_stat ) {
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    switch (proc_buf ? proc_buf->pr_lwp.pr_state : SIDL) {
  #else
  	    switch ( proc_buf->p_stat ) {
  #endif
***************
*** 566,597 ****
  #endif
  #else
  	    sprintf( string, "/proc/%d/stat", pid );
! 	    if ((fp = fopen( string, "r")) == NULL) return NULL;
! 	    fgets( buf, sizeof(buf), fp );
! 	    cp = buf;
! 	    for ( i = 0 ; i < 2 ; ++i ) {	/* skip two fields */
! 		while ( *cp != ' ')
  		    ++cp;
! 		++cp;
! 	    }
  
! 	    switch ( *cp ) {
! 		case 'R':
  	    		long_return = 1;	/* running */
  			break;
! 		case 'S':
  	    		long_return = 2;	/* runnable */
  			break;
! 		case 'D':
! 		case 'T':
  	    		long_return = 3;	/* notRunnable */
  			break;
! 		case 'Z':
! 		default:
  	    		long_return = 4;	/* invalid */
  			break;
! 	    }
!             fclose(fp);
  #endif
  	    return (u_char *)&long_return;
  
--- 578,611 ----
  #endif
  #else
  	    sprintf( string, "/proc/%d/stat", pid );
! 	    if ((fp = fopen( string, "r")) != NULL) {
! 		fgets( buf, sizeof(buf), fp );
! 		cp = buf;
! 		for ( i = 0 ; i < 2 ; ++i ) {	/* skip two fields */
! 		    while ( *cp != ' ')
! 			++cp;
  		    ++cp;
! 		}
  
! 		switch ( *cp ) {
! 		    case 'R':
  	    		long_return = 1;	/* running */
  			break;
! 		    case 'S':
  	    		long_return = 2;	/* runnable */
  			break;
! 		    case 'D':
! 		    case 'T':
  	    		long_return = 3;	/* notRunnable */
  			break;
! 		    case 'Z':
! 		    default:
  	    		long_return = 4;	/* invalid */
  			break;
! 		}
!                 fclose(fp);
! 	    } else
! 		long_return = 4;		/* invalid */
  #endif
  	    return (u_char *)&long_return;
  
***************
*** 603,610 ****
  				 */
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    long_return = proc_buf->pr_time.tv_sec * 100 +
! 			  proc_buf->pr_time.tv_nsec/10000000;
  #else
  	    long_return = proc_buf->p_utime*100 +
  	    		  proc_buf->p_stime*100;
--- 617,624 ----
  				 */
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    long_return = proc_buf ? proc_buf->pr_time.tv_sec * 100 +
! 			  proc_buf->pr_time.tv_nsec/10000000 : 0;
  #else
  	    long_return = proc_buf->p_utime*100 +
  	    		  proc_buf->p_stime*100;
***************
*** 645,651 ****
  	    long_return = (proc_buf.pst_rssize << PGSHIFT)/1024;
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    long_return = proc_buf->pr_rssize;
  #else
  	    long_return = proc_buf->p_swrss;
  #endif
--- 659,665 ----
  	    long_return = (proc_buf.pst_rssize << PGSHIFT)/1024;
  #elif defined(solaris2)
  #if _SLASH_PROC_METHOD_
! 	    long_return = proc_buf ? proc_buf->pr_rssize : 0;
  #else
  	    long_return = proc_buf->p_swrss;
  #endif

Shared Libs 3 -- 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

  Hi,

The master agent has been created with:

   ./configure --with-cc=cc \
        '--with-mib-modules=agentx/master' \
        '--with-out-mib-modules=ucd_snmp' \
        '--with-cflags=-Xa' \
        --with-mibdirs="/opt/ucd-snmp/mibs"

The subagent has been created with:

    ./configure --with-cc=cc \
        '--with-mib-modules=agentx/subagent host' \
        '--with-out-mib-modules=ucd_snmp mibII' \
        '--with-cflags=-Xa' \
        --with-mibdirs="/opt/ucd-snmp/mibs"

ls -lF on snmplib/Makefile:

master agent : ... 820432 Dec  8 17:05 libsnmp-0.4.2.so
subagent     : ... 820412 Dec  8 17:11 libsnmp-0.4.2.so

so, there is 20b between the two libs.

The snmplib/Makefile is identical in both cases.

but a 'diff -wl' applied on the config.h shows:

18c18
< #define DEFAULT_MIBS
"IP-MIB:IF-MIB:TCP-MIB:UDP-MIB:SNMPv2-MIB:RFC1213-MIB:HOST-RESOURCES-MIB:HOST-RESOURCES-TYPES:SNMP-FRAMEWORK-MIB:SNMP-MPD-MIB:SNMP-USER-BASED-SM-MIB:SNMP-NOTIFICATION-MIB:SNMP-TARGET-MIB:SNMPv2-TM"
---
> #define DEFAULT_MIBS "IP-MIB:IF-MIB:TCP-MIB:UDP-MIB:SNMPv2-MIB:RFC1213-MIB:SNMP-VIEW-BASED-ACM-MIB:SNMP-COMMUNITY-MIB:SNMP-FRAMEWORK-MIB:SNMP-MPD-MIB:SNMP-USER-BASED-SM-MIB:SNMP-NOTIFICATION-MIB:SNMP-TARGET-MIB:SNMPv2-TM"
1046c1046
< #define CONFIGURE_OPTIONS " --with-cc=cc
'--with-mib-modules=agentx/subagent host'
'--with-out-mib-modules=ucd_snmp mibII' --with-cflags=-Xa
--with-mibdirs=/opt/ucd-snmp/mibs"
---
> #define CONFIGURE_OPTIONS " --with-cc=cc --with-mib-modules=agentx/master --with-out-mib-modules=ucd_snmp --with-cflags=-Xa --with-mibdirs=/opt/ucd-snmp/mibs"



The DEFAULT_MIBS variable is used in the snmplib/mib.c

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 ?

NET-SNMP Proxy Agent

[Stegehuis, M. (Marcel)** C. ** <mst...@lu...>]

Question: We used UCD/NET-SNMP to create a proxy agent. We extended the
SNMPd with our mib.

One problem here is that a SNMP request with several requests in it is split
into each request and is handled synchronisly. Is there a kind of
a-synchronuos way to do this ?

Regards,

Marcel

Shared Libs 2 -- SOS

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

  Hi,


Would you mind to tell me what is wrong in the following:

The shared libs allow different applications to share the same
functions. A shared lib optimizes the memory usage because it is loading
only once by the system, but can be used by several applications.

The size of the shared libs produced by ucd-snmp changes from one agent
to another.

Thus the shared libs produced by ucd-snmp are agent/mibs specific.

Thus the shared libs produced during the compilation of a subagent 'A'
can only be used by the subagent 'A'.

Thus each agent and subagent needs its own shared libs.

Thus these are no more shared libs.

Thus static libs are better in this case.

Thus everybody should used '--desable-shared' with 'configure'.


???? !!!! please help me and tell me how to make real shared libs that
can be used by agent and subagent at the same time ???? !!!!


thanks in advance.


   Jerome


PS: see previous email 'HELP ON LIBRARIES PROBLEMS' of the Coders
mailling list, to check the size of shared libs upon different
agent/subagent compilation.

Re: 4.2 agent core dump on 64 bits Solaris

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

> >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.

Thanks,

Anders Ellefsrud
an...@ba...

=========

*** agent/mibgroup/ucd-snmp/dlmod.c.patched     Sun Dec 10 23:20:57 2000
--- agent/mibgroup/ucd-snmp/dlmod.c     Mon Dec 11 00:15:58 2000
***************
*** 304,312 ****
  static int
  header_dlmod(struct variable *vp,
             oid *name,
!            int *length,
             int exact,
!            int *var_len,
             WriteMethod **write_method)
  {
  #define DLMOD_NAME_LENGTH 10
--- 304,312 ----
  static int
  header_dlmod(struct variable *vp,
             oid *name,
!            size_t *length,
             int exact,
!            size_t *var_len,
             WriteMethod **write_method)
  {
  #define DLMOD_NAME_LENGTH 10

Re: IPX support

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

Thank you!  (I should've mentioned that I was working on this too.)  It
worked well against my HP JetDirect EX Plus (J2591A).

I can't wait to try it out at work on a building full of JetDirect EIO
cards configured for IPX only.  It'll be nice to be able to monitor 'em
from my Linux workstation.

-- 
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?

Re: Sprintf versions of fprint_objid, fprint_value in the C code.

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

On Sat, 9 Dec 2000 12:25:59 -0800 "Daniel L. Needles" <dne...@jp...> wrote:
>Hello,
>  I have a need to massage the text that is returned by these functions.  Are
> there sprint equivallents?  

Yes, they all have a sprint counterpart. Actually all the fprint_xxx functions 
are implemented as a sprint_xxx followed by fprintf

/Niels

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

Sprintf versions of fprint_objid, fprint_value in the C code.

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

Hello,
  I have a need to massage the text that is returned by these functions. =
 Are there sprint equivallents? =20

Thanks,
Daniel L. Needles

Re: 4.2 agent core dump on 64 bits Solaris

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

On Sat, 09 Dec 2000 12:12:46 +0100 Anders Ellefsrud <an...@ba...> wrote:
>(sorry, it appears impossible to use sourceforge today
>to register this in the bug-base - i'll try mail instead)
>
>When compiling 4.2 on 64 bits solaris 8 and doing an snmpwalk, the
>agent fails in asn1.c as indicated below. I do not understand the inner
>life of snmpd, and seems unable to track this problem down.
>
>If compiled in an 32 bits environment on the same host, the agent runs
>flawless. When compiled with Solaris(sparc) cc -xarch=v9a (64 bits code)
>it fails when it dereferences a null pointer (below).

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?

--- agent/mibgroup/ucd-snmp/dlmod.c     2000/11/22 21:48:23     1.6
+++ agent/mibgroup/ucd-snmp/dlmod.c     2000/12/09 16:35:47
@@ -43,6 +43,8 @@
 #include <dlfcn.h>
 #include "dlmod.h"

+static long long_return;
+
 static struct dlmod *dlmods = NULL;
 static int          dlmod_next_index = 1;
 static char         dlmod_path[1024];
@@ -350,7 +352,8 @@
     /* this is where we do the value assignments for the mib results. */
     switch (vp->magic) {
     case DLMODNEXTINDEX:
-       return (unsigned char *)&dlmod_next_index;
+        long_return = dlmod_next_index;
+       return (unsigned char *)&long_return;
     default:
        DEBUGMSGTL(("dlmod", "unknown sub-id %d in var_dlmod\n", vp->magic));
     }
@@ -452,7 +455,8 @@
        return dlm->error;
     case DLMODSTATUS:
        *write_method = write_dlmodStatus;
-       return (unsigned char *) &dlm->status;
+       long_return = dlm->status;
+       return (unsigned char *) &long_return;
     default:
        DEBUGMSGTL(("dlmod", "unknown sub-id %d in var_dlmodEntry\n",
                    vp->magic));

/Niels


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

4.2 agent core dump on 64 bits Solaris

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

(sorry, it appears impossible to use sourceforge today 
to register this in the bug-base - i'll try mail instead)

When compiling 4.2 on 64 bits solaris 8 and doing an snmpwalk, the
agent fails in asn1.c as indicated below. I do not understand the inner
life of snmpd, and seems unable to track this problem down.

If compiled in an 32 bits environment on the same host, the agent runs
flawless. When compiled with Solaris(sparc) cc -xarch=v9a (64 bits code)
it fails when it dereferences a null pointer (below).

Reproduce with: 
$ snmpgetnext localhost public enterprises.ucdavis.ucdExperimental.ucdDlmodMIB.dlmodNextIndex

It does not appear to make a difference if I compile in dlmod or not,
it fails when it hits this location in the tree no matter.

I may be able to help tracking this down if someone can help me
with what to look for. Anyone need more info from me on this? Mail me.

Regards,
	Anders Ellefsrud
	an...@ba...

[...]
dumph_recv:           Name
dumpx_recv:            06 0A 2B 06 01 04 01 8F 65 0D 0E 01 
dumpv_recv:              ObjID: enterprises.ucdavis.ucdExperimental.ucdDlmodMIB.dlmodNextIndex
trace:  snmp_api.c, 3430
dumph_recv:           Value
trace:  callback.c, 90
callback: START calling callbacks for maj=1 min=5
trace:  callback.c, 96
callback: calling a callback for maj=1 min=5
trace:  mibII/vacm_vars.c, 663
mibII/vacm_vars: vacm_in_view: ver=1, source=7f000001, community=public
trace:  mibII/vacm_vars.c, 701
mibII/vacm_vars: vacm_in_view: sn=anonymousSecName000, gn=anonymousGroupName000, Done checking setup
trace:  callback.c, 105
callback: END calling callbacks for maj=1 min=5 (1 called)
trace:  snmp_vars.c, 438
snmp_vars: Looking for: enterprises.ucdavis.ucdExperimental.ucdDlmodMIB.dlmodNextIndex ...
trace:  snmp_vars.c, 445
snmp_vars: Trying tree: enterprises.ucdavis.ucdExperimental.ucdDlmodMIB ...
trace:  snmp_vars.c, 328
snmp_vars: Trying variable: enterprises.ucdavis.ucdExperimental.ucdDlmodMIB.dlmodNextIndex ...
trace:  snmp_vars.c, 336
snmp_vars: Returned something
trace:  callback.c, 90
callback: START calling callbacks for maj=1 min=0
trace:  callback.c, 96
callback: calling a callback for maj=1 min=0
trace:  mibII/vacm_vars.c, 663
mibII/vacm_vars: vacm_in_view: ver=1, source=7f000001, community=public
trace:  mibII/vacm_vars.c, 701
mibII/vacm_vars: vacm_in_view: sn=anonymousSecName000, gn=anonymousGroupName000, vn=anonymousView000trace:  vacm.c, 300
vacm:getView: , found, vt=1
trace:  callback.c, 105
callback: END calling callbacks for maj=1 min=0 (1 called)
trace:  callback.c, 90
callback: START calling callbacks for maj=1 min=0
trace:  callback.c, 96
callback: calling a callback for maj=1 min=0
trace:  mibII/vacm_vars.c, 663
mibII/vacm_vars: vacm_in_view: ver=1, source=7f000001, community=public
trace:  mibII/vacm_vars.c, 701
mibII/vacm_vars: vacm_in_view: sn=anonymousSecName000, gn=anonymousGroupName000, vn=anonymousView000trace:  vacm.c, 300
vacm:getView: , found, vt=1
trace:  callback.c, 105
callback: END calling callbacks for maj=1 min=0 (1 called)
trace:  snmp_api.c, 2307
snmp_send: Building SNMPv2 message...
trace:  snmp_api.c, 2310
dumph_send:   PDU-RESPONSE
trace:  snmp_api.c, 2592
snmp_pdu_rbuild: starting
trace:  snmp_api.c, 2607
dumph_send:     VarBind
trace:  snmp.c, 311
dumph_send:       Value
signal SEGV (no mapping at the fault address) in asn_rbuild_int at line 2078 in file "asn1.c"
 2078       int testvalue = (*intp < 0) ? -1 : 0;
(/opt/SUNWspro/bin/../WS6/bin/sparcv9/dbx) where
=>[1] asn_rbuild_int(data = 0xffffffff7fff621f "\xc0", datalength = 0xffffffff7fff4210, type = '\002', intp = (nil), intsize = 0), line 2078 in "asn1.c"
  [2] snmp_rbuild_var_op(data = 0xffffffff7fff621f "\xc0", var_name = 0x1000871e0, var_name_len = 0x1000871c0, var_val_type = '\002', var_val_len = 0, var_val = (nil), listlength = 0xffffffff7fff4210), line 315 in "snmp.c"
  [3] snmp_pdu_rbuild(pdu = 0x100086ff0, cp = 0xffffffff7fff621f "\xc0", out_length = 0xffffffff7fff4210), line 2610 in "snmp_api.c"
  [4] _snmp_build(session = 0x100086860, pdu = 0x100086ff0, packet = 0xffffffff7fff621f "\xc0", out_length = 0xffffffff7fff4210), line 2311 in "snmp_api.c"
  [5] snmp_build(pss = 0x100086860, pdu = 0x100086ff0, packet = 0xffffffff7fff621f "\xc0", out_length = 0xffffffff7fff4210), line 2438 in "snmp_api.c"
  [6] _sess_async_send(sessp = 0x1000c5e50, pdu = 0x100086ff0, callback = (nil), cb_data = (nil)), line 3753 in "snmp_api.c"
  [7] snmp_sess_async_send(sessp = 0x1000c5e50, pdu = 0x100086ff0, callback = (nil), cb_data = (nil)), line 3849 in "snmp_api.c"
  [8] snmp_async_send(session = 0x100086860, pdu = 0x100086ff0, callback = (nil), cb_data = (nil)), line 3656 in "snmp_api.c"
  [9] snmp_send(session = 0x100086860, pdu = 0x100086ff0), line 3639 in "snmp_api.c"
  [10] handle_snmp_packet(operation = 1, session = 0x100086860, reqid = 328510638, pdu = 0x1000869b0, magic = (nil)), line 634 in "snmp_agent.c"
  [11] _sess_read(sessp = 0x1000c5e50, fdset = 0xffffffff7fffcb98), line 4246 in "snmp_api.c"
  [12] snmp_sess_read(sessp = 0x1000c5e50, fdset = 0xffffffff7fffcb98), line 4268 in "snmp_api.c"
  [13] snmp_read(fdset = 0xffffffff7fffcb98), line 3920 in "snmp_api.c"
  [14] receive(), line 781 in "snmpd.c"
  [15] main(argc = 4, argv = 0xffffffff7ffff978), line 649 in "snmpd.c"

Re: Future Plans - testing

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

On Fri, 08 Dec 2000 13:13:27 -0500 "Michael J. Slifcak" <msl...@is...> wrote:
>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.

I can only agree. We do need some formalized testing, and a repository for the
results that we obtain.

>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.
>
>The attached results (yes, recent agent) show four common platforms,
>and please note that they all have some minor problems, from the
>SilverCreek tester's point of view.   There may be disagreement on
>the value used, or the choice of test setup, but I believe we can
>make improvements persist beyond the restructuring efforts that
>are now being considered.

I have just committed fixes to some of the problems that SilverCreek detected.
On the other hand, some of the things that it reports seem bogus to me. The
Float report is certainly bogus, and when I try the mrIndex thing by hand, it
shows no problem. And it didn't detect the bad indexing in the
vacmViewTreeFamilyEntry that I just fixed.

Btw, you can compile the UCD mibs for it (even if you only have the evaluation
version) with smidump from libsmi like this:

smidump -f mosy /usr/local/share/snmp/mibs/UCD-SNMP-MIB.txt >
/usr/local/silvercreek6/mibs/ucd-snmp-mib.defs

then you will get rid of its comments about not being able to verify the types
and values of the ucdavis subtree.

/Niels


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

Re: Future Plans - testing

[Michael J. S. <msl...@is...>]

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.

The recent test suite additions were helpful to minimize
package regression, and build user confidence that
the libraries (like openssl) were actually used, or not.

I think moving forward, we should strive to develop unit tests
for the modules we would like to improve.  This way, we can
be sure that side effects can be quickly fixed.

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.

The attached results (yes, recent agent) show four common platforms,
and please note that they all have some minor problems, from the
SilverCreek tester's point of view.   There may be disagreement on
the value used, or the choice of test setup, but I believe we can
make improvements persist beyond the restructuring efforts that
are now being considered.

Thanks for your patience and cooperation.
-Mike Slifcak, Internet Security Systems, Inc.

HELP ON LIBRARIES PROBLEMS

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

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

    Hi,

Wes, this is the last email:

Jerome> Thus, the 3 libraries (libucdagent - libucdmibs - libsnmp) are
always
Jerome> the same. 
Jerome> i.e.: they can be used at run time, by a subagent 'B' even if
they have
Jerome> been produced by the Makefile during the compilation of a
subagent 'A'.

Wes> Yes.

Wes> Almost.  The libucdmibs changes, but you probably don't need to be
Wes> concerned with it for what you're doing.


I created a master agent with:

    ./configure --with-cc=cc \
        '--with-mib-modules=agentx/master' \
        '--with-out-mib-modules=ucd_snmp' \
        '--with-cflags=-Xa' \
        --with-mibdirs="/opt/ucd-snmp/mibs"
    make


Here is the result of the unix command 'ls -lF' for (libucdagent -
libucdmibs - libsnmp - snmpd binary) produced:

-rwxr-xr-x   1 jjargot  calapp     98688 Dec  8 17:07
libucdagent-0.4.2.so*
-rw-r--r--   1 jjargot  calapp     90012 Dec  8 17:07 libucdagent.a
-rwxr-xr-x   1 jjargot  calapp    735164 Dec  8 17:06
libucdmibs-0.4.2.so*
-rw-r--r--   1 jjargot  calapp    685880 Dec  8 17:07 libucdmibs.a

-rwxr-xr-x   1 jjargot  calapp     30268 Dec  8 17:07 snmpd*

-rwxr-xr-x   1 jjargot  calapp    820432 Dec  8 17:05 libsnmp-0.4.2.so*
-rw-r--r--   1 jjargot  calapp    775396 Dec  8 17:05 libsnmp.a


I created a subagent with:

    ./configure --with-cc=cc \
        '--with-mib-modules=agentx/subagent host' \
        '--with-out-mib-modules=ucd_snmp mibII' \
        '--with-cflags=-Xa' \
        --with-mibdirs="/opt/ucd-snmp/mibs" 
    make 

Here is the result of the unix command 'ls -lF' for (libucdagent -
libucdmibs - libsnmp - snmpd binary) produced:

-rwxr-xr-x   1 jjargot  calapp     99204 Dec  8 17:11
libucdagent-0.4.2.so*
-rw-r--r--   1 jjargot  calapp     90644 Dec  8 17:11 libucdagent.a
-rwxr-xr-x   1 jjargot  calapp    703940 Dec  8 17:11
libucdmibs-0.4.2.so*
-rw-r--r--   1 jjargot  calapp    657588 Dec  8 17:11 libucdmibs.a

-rwxr-xr-x   1 jjargot  calapp     30252 Dec  8 17:11 snmpd*

-rwxr-xr-x   1 jjargot  calapp    820412 Dec  8 17:11 libsnmp-0.4.2.so*
-rw-r--r--   1 jjargot  calapp    775384 Dec  8 17:11 libsnmp.a



The size of every files are NOT constant upon the two different
compilation.



? So, The libraries produced are all different ?

? So, The libraries are agent/mibs specific ?

? If so, there is no use to have dynamic libraries, static ones are the
only usefull ?



What do you think about it ?


       Jerome.

Re: Future Plans II - Library

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

> > >     I/O handling
> > 
> >                                             Actually though, I'm not sure 
> > there is all that much to be gained in doing this.  The addition of the 
> > register_{read,...}fd routines was the major step -- they're basically the 
> > logical inverse of the snmp_select_info type routines.
> 
>  Exactly - they're logically related, but handled completely separately.
> One of my pet hates is duplicated code - and currently the agent has
> three sets of more-or-less equivalent actions, one after the other.
> This makes me weep!   The xxx_fd handling is the most flexible, why
> not use it (or something similar) for everything?

  Yes -- I see what you mean.  At the very least I guess the SMUX stuff 
could use the generic fd interface.

> >  Isn't this agent-specific though?
> 
> Currently, yes.   What I'm asking is whether we could/should consider
> moving this level of flexibility within the library - maybe not in
> this precise form, but something with the same general effect.
>   It *might* be that the agent is the only thing that needs to make use
> of it, but how do we know?   It's not so long since we were having the
> same discussion about config files - why would anything other than the
> agent need to worry about them?

  What I was getting at is that there aren't really any long-running select() loops in the library, which is when you'd want this register_fd type of functionality.  It seems that the more natural way to use the library is to have an external select() loop somewhere else in the application, and add in the fds given by snmp_select_info (in fact this is exactly what the agent does).  This is what I meant when I said that it's the logical inverse of the register_fd functions.  So I think essentially what I am saying is that the functionality is already there.  Er.

  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".  (In fact you pass what is essentially a class with methods for reading, writing, closing the socket, formatting addresses etc. rather than just the socket).  Is this more what you were getting at?

John 

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

Re: Future Plans I - MIB

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

>>>>> On Fri, 08 Dec 2000 15:27:24 +0000, Dave Shield <D.T...@cs...> said:

[dlmod]
Wes> (it needs indexing by name as well).

Dave> By name or by OID?

It's a mib module that could be implementing multiple OID registrations.

Dave> I was particularly thinking of the dskTable, which seems to be
Dave> equivalent to the applying an event threshold filter, to the
Dave> appropriate HostRes table.  If there was a simple config
Dave> directive to set this up, would we need to keep the dskTable?

Good point.  Guess not.

Dave> Is the indexing *inevitably* going to be string based?
Dave> I haven't gone through all the tables to check, but is there
Dave> always a suitable (meaningful) label to use?

For most of them yes.  proc/disk/extTable all should have string
indexes.  Right now, if you want to monitor only one of the entries in
a manager and you change the configuration file, the entries get
re-numbered in the table.  Bad bad.

Dave> For example, the laTable could quite reasonably be indexed by
Dave> the integers 1,5,10, and per-CPU statistics would most naturally
Dave> be indexed using arbitrary integers (e.g. simple-table style, or
Dave> re-using the hrDeviceIndex values).

Yes, the other tables may be different...  We should examine them all
carefully.

Dave> But if you come up with a strawman proposal, we can start
Dave> developing from there.

I'll try to put one together shortly.

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

Re: Future Plans I - MIB

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

Wes> Do we roll in the dlmod table into the extensibility section (either
Wes> way)

Yes - that makes more sense than putting it in the 'internal' group.
I don't think there's much point in leaving it on its own.

Wes>                        (it needs indexing by name as well).

By name or by OID?



Dave> Another point to consider:
Dave> if we get a workable implementation of the DisMan Event MIB, how
Dave> much (if any) of the existing monitoring code is rendered redundant?

Wes> None of it.  The disman mibs merely provide us with the ability to do
Wes> standardized alarm type processing.

Fair enough.

I was particularly thinking of the dskTable, which seems to be equivalent
to the applying an event threshold filter, to the appropriate HostRes table.
If there was a simple config directive to set this up, would we need to
keep the dskTable?
   (I'm happy for the answer to be yes - I just want to make sure
that it's not just yes by inertia!)

Wes> However, IMHO, the disman mibs are extremely complex in nature and an
Wes> overkill for simple tasks.

Agreed - but we probably can (and should) hide a lot of this with
suitable configure directive.   Regardless of what enterprise
extensions we support.



Wes> If we do change things, I want to restructure *all* the tables

Wes> 99% of what I want to do is change the indexing for most of the tables
Wes> to a string and add persistence for rw usage.

Is the indexing *inevitably* going to be string based?
I haven't gone through all the tables to check, but is there
always a suitable (meaningful) label to use?

  For example, the laTable could quite reasonably be indexed by the
integers 1,5,10,  and per-CPU statistics would most naturally be indexed
using arbitrary integers (e.g. simple-table style, or re-using the
hrDeviceIndex values).
  The list of registered modules could be indexed by module name, arbitrary
integer or by OID root, depending on precisely how they are intended to be
used.
  Strings may indeed prove to be the best index in each case, but we
shouldn't take that for granted.

   But if you come up with a strawman proposal, we can start developing
from there.

Dave

Re: SOS on dynamic libraries

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

>>>>> On Fri, 08 Dec 2000 11:00:27 +0100, Jerome Jargot <Jer...@fe...> said:

Jerome> what are lib*.la and lib*.lai ???
Jerome> When are they used ???

They are only files created and used by the libtool command.  Thats all.
(Go ahead and look at them, they are text)

Jerome> Thus, the 3 libraries (libucdagent - libucdmibs - libsnmp) are always
Jerome> the same. 
Jerome> i.e.: they can be used at run time, by a subagent 'B' even if they have
Jerome> been produced by the Makefile during the compilation of a subagent 'A'.

Yes.

Almost.  The libucdmibs changes, but you probably don't need to be
concerned with it for what you're doing.

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

Moving ucd-snmp -> net-snmp

[Michael J. S. <msl...@is...>]

How will changes we make tomorrow affect existing installations ?

One of the most appealing features of the ucd-snmp package (now,
net-snmp)
is how easily it can be deployed.  And there are external packages
that have come to rely on the library features.  

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

1) Whose libsnmp.a, libxxmib.a is that anyway ?  CMU ? UCD ? net-snmp ?
   libnetsnmp.4.2.0 ?
   And, include file location: is it /usr/include/ucd-snmp ?

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

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

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


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.

Regards,
-Mike Slifcak, Internet Security Systems, Inc.

Re: Future Plans I - MIB

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

>>>>> On Fri, 08 Dec 2000 11:15:57 +0000, Dave Shield <D.T...@cs...> said:

Dave> That's a relief :-)  I was concerned that you might prefer to keep
Dave> everything under the old 'ucdavis' tree.

I'll go register for a new enterprise number.

Dave> We could either have "all the monitoring stuff" together, or divide
Dave> things by subject area (NET-SNMP-DISK-MIB, NET-SNMP-PROC-MIB, etc)
Dave> The first feels somewhat less fragmented - the second is easier to
Dave> update and develop.

Having one table per mib is rather ridiculous, IMHO (and a waste of
inodes).  I also think its easier to keep similarly functional items
together for purposes of clarity.

Dave> How confident are we about getting things right first time? :-)

One word: Ha!

I do suggest we pass the eventually re-written mibs by David P, and
Juergen to make sure they don't think we're crazy.  (If we're lucky,
they'll read this anyway)

Dave> Strawman proposal 1:

Dave> Monitoring	prTable, dskTable, fileTable
Dave> Extensibility	extTable, (new) passTable
Dave> System		memory, laTable, systemStats
Dave> Disk		diskIOTable
Dave> Internal	version, snmperrs, mrTable, dlmodTable

Dave> Strawman proposal 2:

Dave> Processes	prTable, memory
Dave> Extensibility	extTable, (new) passTable
Dave> CPU		laTable, systemStats
Dave> Disk		diskIOTable, dskTable, fileTable
Dave> Internal	version, snmperrs, mrTable, dlmodTable

Hmm.  Now you have me stumped.  I like them both (for different
reasons).  For the first one, I'd probably make the Disk group more of
a "Performance" section instead.

I guess the second one makes more sense.  Maybe.  Kind of.  Guess I'll
think more about it.

Do we roll in the dlmod table into the extensibility section (either
way) or do we leave it in its own mib (it needs indexing by name as well).

Dave> Another point to consider:
Dave> if we get a workable implementation of the DisMan Event MIB, how
Dave> much (if any) of the existing monitoring code is rendered redundant?

None of it.  The disman mibs merely provide us with the ability to do
standardized alarm type processing.  The script mib, however, would
provide us the ability to make things like the extTable less useful.
However, IMHO, the disman mibs are extremely complex in nature and an
overkill for simple tasks.  The extTable is much easier to use for a
quick simple basis (but you loose the features that come with the
complexity).

It's possible if we ever supported the script mib (aside from jasmin,
of course) we could sort of merge the two together so that the "exec"
tokens would get mapped into script mib entries and the extTable could
still exist as an extrapolation of the script mib that handles the
"run-it-by-pushing-a-button, get-the-results, display-the-error-code,
display-the-first-line-of-output" half of what the script mib produces.

Wes> If we do change things, I want to restructure *all* the tables
Wes> mentioned above.  Almost all of them should be indexed by strings,
Wes> contain a RowStatus column, etc.

Dave> OK - do you wish to come up with a strawman proposal for this?

I will.

99% of what I want to do is change the indexing for most of the tables
to a string and add persistence for rw usage.  The "exec OID" token
usage needs to be completely shot and rewritten.

-- 
Wes Hardaker
NAI Labs
Network Associates

Re: Future Plans III - Agent

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

> >    Table handling
> 
>   Coming up with a reasonably generic set of routines (and good 
> documentation, crucially) for handling common features like this would be 
> very useful indeed.

That was more or less my feeling.   Currently we've got Wes' "complex tables",
and my (experimental) "cached tables".  One of the mibJJ implementations
(interfaces, I think), tries to handle fixed indexes based on the name.
This could probably be generalised without too much trouble.

   What I'm mostly wondering is how much these have in common, and how much
they should be three separate implementations.


> >    Existing modules
> 
>   Definitely.  I think it would clarify things a lot if platform-specific 
> code (of which there is necessarily a lot esp. in mib-2) was broken out into 
> separate files for each architecture, and the autoconf system used to 
> compile the appropriate parts.

That's one possibility, which has been used to good effect in some of the
UCD-specific modules.  An alternative, as appears in the mibJJ re-write,
is to have #ifdef'ed architecture-specific routines, that retrieve the
underlying data and save it in a standardised form.
   It may be that different approaches are appropriate in different cases,
depending on the data being manipulated.

I'm also very keen to remove (or at least reduce) the current #ifdef tangle!



> >     MIBs and "internal" features
> > 	   How closely linked should the features and the corresponding
> > 	MIBs be?
> 
>   For things like VACM, targets and notifications, I think the integration 
> has to be pretty tight (shared data structures etc.).

Indeed.   But does the MIB structure determine the implementation of
the feature, or vice versa?

>                                                        It should be possible 
> to include or exclude the externally-visible accessor functions allowing 
> viewing/modification of the tables quite easily though.

Well, currently that's possible by appropriate --with-out-mib-module calls.
But that also removes the functionality, as well as the visible MIB.
I'm partly proposing that these should be separated (i.e. allow VACM code
without necessarily including the VACM MIB), and partly asking whether
the feature should be removeable at all.

 

Dave

Re: Future Plans II - Library

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

> > 	It has been suggested that we might consider using externally
> > 	provided packages for certain aspects of the library support

>   Hmm.  I would be a little reluctant to go down this track.  Isn't the 
> danger in multiplying the dependencies that there is more scope for 
> incompatibilities and version problems?

  Quite possibly.  I've certainly got mixed feelings about this one.
There's two ways of approaching this (if we decide it's worth doing).

One is to use an "externally installed" package - i.e. say "this suite
relies on the use of a pre-installed libsmi" (for example).  The other
is to ship the relevant software together with the suite itself
(suitably acknowledged, of course).  That latter should at least reduce
the  version-compatability problems.
  Whether this second approach is possible depends in part on the licensing
situation of the relevant bits and pieces.   Whether either is desirable
is another question.  "It ain't broke, don't fix it" compared with
"don't re-invent the wheel".



> >     Programmer APIs
> > 	Should we review the public APIs we provide for those wishing to
> > 	write fairly simple SNMP applications

>   Probably at a fairly low priority?  I would imagine that most people doing 
> this kind of work would be using some kind of scripting language,

Possibly - but by choice, or necessity?
Given that we offer one of the fuller C programming SNMP libraries (at least
among the publically-available offerings), it would be nice to think that
it was reasonably easy to use.
  I had a stab at writing a very simple application a couple of days ago -
just request a couple of objects (using v1/2) and set one value (using v3
authentication).  The requests were reasonably straightforward (if a little
fiddly), but I still haven't got the v3 SET working at all.   Now I may be
missing something simple, but if I'm struggling despite years of exposure
to this project, something's wrong!
 

> >     I/O handling
> 
>                                             Actually though, I'm not sure 
> there is all that much to be gained in doing this.  The addition of the 
> register_{read,...}fd routines was the major step -- they're basically the 
> logical inverse of the snmp_select_info type routines.

 Exactly - they're logically related, but handled completely separately.
One of my pet hates is duplicated code - and currently the agent has
three sets of more-or-less equivalent actions, one after the other.
This makes me weep!   The xxx_fd handling is the most flexible, why
not use it (or something similar) for everything?

>  Isn't this agent-specific though?

Currently, yes.   What I'm asking is whether we could/should consider
moving this level of flexibility within the library - maybe not in
this precise form, but something with the same general effect.
  It *might* be that the agent is the only thing that needs to make use
of it, but how do we know?   It's not so long since we were having the
same discussion about config files - why would anything other than the
agent need to worry about them?




Dave

Re: Future Plans III - Agent

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

>    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?

  Your proposal to do something which is extensible was a good one in my 
view.  Whatever happens, I think that the current API must be kept for 
compatibility.  An extra argument to the register_mib functions could be 
used to request which API is used for calling MIB functions, allowing 
migration to the newer API on a per-module basis.  Having said that, though, 
I've never actually felt restricted by the current API -- guess I'm just a 
lucky guy!

>    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?

  Coming up with a reasonably generic set of routines (and good 
documentation, crucially) for handling common features like this would be 
very useful indeed.  There must be a lot of reinvention of the wheel going 
on amongst MIB implementors at the moment.

>    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)

  Definitely.  I think it would clarify things a lot if platform-specific 
code (of which there is necessarily a lot esp. in mib-2) was broken out into 
separate files for each architecture, and the autoconf system used to 
compile the appropriate parts.  This may lead to some duplication of code 
(though naturally this should be minimised) but the pay-off ought to be an 
improvement in code readability and maintainability (no horrendous 
multi-page nestsed #ifdef nightmares!).

>     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?

  For things like VACM, targets and notifications, I think the integration 
has to be pretty tight (shared data structures etc.).  It should be possible 
to include or exclude the externally-visible accessor functions allowing 
viewing/modification of the tables quite easily though.

>     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.

  Probably quite low priority?  As in `it would be nice, but...'.

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

  I think this would be a portability nightmare, and I don't think the gains 
justify the additional complexity.  I can see the appeal in terms of 
parallelising any waiting for system calls or whatever to return data, but 
how often is this really a problem?  Maybe we could get a handle on whether 
this is worthwhile by doing a survey on the average number of varbinds in a 
request/response?  My guess would be that it's a low number.  As has been 
discussed on the list recently (ish) it's often/sometimes/occasionally 
(depending on your POV and the particular variable in question) acceptable 
to cache this type of data.

  This is of course a totally separate matter from making the library and 
agent code thread-safe, which is a very good idea.

>     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.

  Following that old old mantra of being liberal in what you accept and conservative in what you send, this is bound to be a good way of shaking down that stuff and coming up with a really robust subsystem.  Definitely worth doing.

  Phew.  That'll do for now.

John

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

Re: SOS dynamic libraries

[Michael J. S. <msl...@is...>]

The *.la, *.lo, and *.lai files are the domain of libtool,
which has extensive documantation, just not copied in this project.
Suffice to say they are supporting the ability of libtool to
locate candidate files for compiling, linking, and installing
the library binaries.


"make install prefix=MYDIR/opt" will install the ucd-snmp package
hierarchy under MYDIR/opt.  I believe that some of the text files,
particularly several manual pages,
will need to be adjusted to remove MYDIR from them.

Sorry for lame excuse not knowing which files embed the prefix.
If you search for "$prefix" in all Makefile.in files, you'll
be able to build the list of adjusted files.

Best Regards,
-Mike Slifcak 

Jerome Jargot wrote:
> 
> version  : ucd-snmp version 4.2
> system   : SunOS 5.7 Generic_106541-11 sun4u sparc SUNW,Ultra-250
> protocol : AgentX
> 
>    Hello,
> 
> first off, thanks very much.
> 
> Wes Hardaker wrote:
> >
> > >>>>> On Wed, 06 Dec 2000 18:11:27 +0100, Jerome Jargot <Jer...@fe...> said:
> >
> > Jerome> The ucd-snmp/agent/.libs/snmpd is a binary which seems to use
> > Jerome> the dynamic libraries:
> >
> > Jerome> - ucd-snmp/agent/.libs/libucdagent-0.4.2.so
> > Jerome> - ucd-snmp/agent/.libs/libucdmibs-0.4.2.so
> > Jerome> - ucd-snmp/snmplib/.libs/libsnmp-0.4.2.so
> >
> > Jerome> Is it true ?
> >
> > Jerome> So, could it be possible to remove all lib*.a, lib*.la,
> > Jerome> lib*.lai ?  (will the master agent be working after that ?)
> >
> > You should not delete anything from the build tree.  libtool makes use
> > of these files when you run "make install".  (a binary will be
> > installed, not the shell script)
> 
> I do not need to install the master agent and subagents onto the SUN I'm
> using for compilation.
> I produce a master agent and some subagents, that are standard for my
> company (FERMA). But project workers will customize our products later
> on, for clients, and they are going to produce additional subagents.
> The main line is that I deliver a unix package (pkgadd command), for
> already created agents, and the ucd-snmp directory that allows
> additionnal subagents to be created by project workers.
> 
> ???
> 
> What are the things done during 'make install' that need *.lai and *.la
> and *.a to install the binary ?
> 
> ???
> 
> >
> > Note that by default the package is built with both static and shared
> > libraries.  To turn one or the other off, use --disable-static or
> > --disable-shared when running configure.
> 
> OK, very usefull.
> 
> > Jerome> After compiling a subagent, does it use the same dynamic
> > Jerome> libraries ?  i.e.: if I copy the 3 libraries into
> > Jerome> /usr/stuff/lib, does the master agent AND subagents run well
> > Jerome> using LD_LIBRARY_PATH=/usr/stuff/lib ?
> >
> > In theory.  "make install" is the proper way to go to ensure that
> > things work (and it'll tell you what you need to do if anything).
> >
> 
> I need to make my own install.
> 
> Thanks very much again for all.
> 
>     Jerome
> _______________________________________________
> Net-snmp-coders mailing list
> Net...@li...
> http://lists.sourceforge.net/mailman/listinfo/net-snmp-coders