Hi All,
I generated sub agent code for scalars in HOST-RESOURCES_MIB using:
env MIBS="+HOST-RESOURCES-MIB" mib2c -c mib2c.scalar.conf hrSystem
It generates hrSystem.c and hrSystem.h. Inside the .c file there are two
kind of functions:
a) init_hrSystem (to be called from the sub agent)
b) handle
> "RS" == Robert Story <[EMAIL PROTECTED]> writes:
RS> And I'm saying that any script or C module, poorly coded, can also
RS> hang the agent.
I don't have time to respond to the whole thread at the moment. My
point wasn't that some whacky script can't do harm to the agent.
Certainly there ar
On Wed, 25 Oct 2006 16:28:16 -0700 Wes wrote:
WH> > "RS" == Robert Story <[EMAIL PROTECTED]> writes:
WH>
WH> RS> No, without it a poorly written script hangs. The same could be
WH> RS> said for a non-persist pass script, or even a C module. We can't
WH> RS> cover all the bases.
WH>
WH> No, wi
> "BS" == Bruce Shaw <[EMAIL PROTECTED]> writes:
WH> I'm actually only just over the fence about whether it should go into
WH> 5.4. But I'm over it none the less, because the case is rare and
WH> doing a blocking wait on a PID that will never exit seems broken.
BS> So is that a +1?
It's a +
> "RS" == Robert Story <[EMAIL PROTECTED]> writes:
RS> No, without it a poorly written script hangs. The same could be
RS> said for a non-persist pass script, or even a C module. We can't
RS> cover all the bases.
No, without it the *agent* hangs. It's doing a waitpid on a pid that
never exit
On Wed, 25 Oct 2006 16:57:45 -0400 chris wrote:
CJ> On 20-Oct-2006, at 5:04 PM, Thomas Anders wrote:
CJ>
CJ> > Robert Story wrote:
CJ> >> Darwin 8 & 9 don't include the freeBSD or generic system header,
CJ> >> and thus end
CJ> >> up with no INP_NEXT_SYMBOL header. This simple patch adds the
CJ
On 20-Oct-2006, at 5:04 PM, Thomas Anders wrote:Robert Story wrote: Darwin 8 & 9 don't include the freeBSD or generic system header, and thus end up with no INP_NEXT_SYMBOL header. This simple patch adds the symbol to the darwin 8 & 9 headers. +1, as already said on IRC. My compilations did not re
On Wed, 25 Oct 2006 12:25:34 -0700 Wes wrote:
WH> > "RS" == Robert Story <[EMAIL PROTECTED]> writes:
WH>
WH> RS> Actually, after looking at the code, the closing of the pipe/fd is
WH> RS> a signal to the persist app, which should terminate on that
WH> RS> condition. Thus, I think this is a bug
WH>I'm actually only just over the fence about whether it should go into
WH>5.4. But I'm over it none the less, because the case is rare and
WH>doing a blocking wait on a PID that will never exit seems broken.
So is that a +1?
This communication is intended for the use of the recipient to whic
> "RS" == Robert Story <[EMAIL PROTECTED]> writes:
RS> Actually, after looking at the code, the closing of the pipe/fd is
RS> a signal to the persist app, which should terminate on that
RS> condition. Thus, I think this is a bug in the persist script, not
RS> the agent.
The reason, IMHO, for
> "DS" == Dave Shield <[EMAIL PROTECTED]> writes:
WH> Point of order: I'm not sure Dave has actually said yes even thouh he
WH> posted the patches?
DS> Sorry - I didn't realise I had to vote on my own patch.
DS> I'm sure I remember someone [you, I think] saying that the proposer of
DS> a patc
Dave Shield wrote:
> On 25/10/06, Wes Hardaker <[EMAIL PROTECTED]> wrote:
>> WH> Point of order: I'm not sure Dave has actually said yes even thouh he
>> WH> posted the patches?
>
> Sorry - I didn't realise I had to vote on my own patch.
> I'm sure I remember someone [you, I think] saying that the
On 25/10/06, Alex Burger <[EMAIL PROTECTED]> wrote:
> Dave Shield wrote:
> >> /* If you have openssl 0.9.7 or above, you likely have AES support. */
> >> -/* #undef USE_OPENSSL */
> >> +/* #undef NETSNMP_USE_OPENSSL */
> >>
> >> #ifdef USE_OPENSSL
> >
> > What about that last line of the contex
Dave Shield wrote:
>> /* If you have openssl 0.9.7 or above, you likely have AES support. */
>> -/* #undef USE_OPENSSL */
>> +/* #undef NETSNMP_USE_OPENSSL */
>>
>> #ifdef USE_OPENSSL
>
> What about that last line of the context? Should that have the NS
> prefix too?
Yes, it should. Thanks
+1
>-/* #undef USE_OPENSSL */
>+/* #undef NETSNMP_USE_OPENSSL */
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal and or privileged
information. Please contact us immediately if you are not the intended
recipient of
On 25/10/06, Alex Burger <[EMAIL PROTECTED]> wrote:
> When the Net-SNMP defines were changed to use the NETSNMP_ prefix, one
> was missed in win32/net-snmp-config.h which prevents applications from
> using SSL.
> /* If you have openssl 0.9.7 or above, you likely have AES support. */
> -/* #unde
Alex Burger wrote:
> When the Net-SNMP defines were changed to use the NETSNMP_ prefix, one
> was missed in win32/net-snmp-config.h which prevents applications from
> using SSL. I will apply the following patch to main.
+1
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
-
On 25/10/06, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> In order for it to go into 5.4 I'll need to get feedback from other
> developers as well since we're in lock-down mode on that code branch.
> To me your patch looks good and like the right thing to do. To the
> other developers: please chime i
On 25/10/06, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> WH> Point of order: I'm not sure Dave has actually said yes even thouh he
> WH> posted the patches?
Sorry - I didn't realise I had to vote on my own patch.
I'm sure I remember someone [you, I think] saying that the proposer of
a patch was an a
When the Net-SNMP defines were changed to use the NETSNMP_ prefix, one
was missed in win32/net-snmp-config.h which prevents applications from
using SSL. I will apply the following patch to main.
Alex
Index: net-snmp-config.h
===
On Wed, Oct 25, 2006 at 11:27:19AM -0400, Robert Story wrote:
> You should be getting a SIGPIPE when you select on stdin, since it has been
> closed.
No: SIGPIPE is generated when *writing* to a pipe with no readers on
the other end. *Reading* (or selecting) from a closed pipe just gets
a normal E
On Wed, 25 Oct 2006 11:15:35 -0400 Robert wrote:
RS> On Wed, 25 Oct 2006 06:36:57 -0700 Wes wrote:
RS> WH> > "AN" == Anthony Novatsis <[EMAIL PROTECTED]> writes:
RS> WH> AN> For Net-SNMP version 5.3.1 (sending a SIGTERM to the pass-through
RS> WH> AN> executable).
RS> WH>
RS> WH> In order for
On Mon, 23 Oct 2006 17:52:43 +0200 Anthony wrote:
AN> Normally, the daemon re-reads it's configuration files when sent a HUP
AN> signal. However when using pass_persist, the daemon becomes blocked after
AN> receiving the HUP signal because the daemon calls the waitpid function for
AN> the PID of t
On Wed, 25 Oct 2006 06:36:57 -0700 Wes wrote:
WH> > "AN" == Anthony Novatsis <[EMAIL PROTECTED]> writes:
WH> AN> For Net-SNMP version 5.3.1 (sending a SIGTERM to the pass-through
WH> AN> executable).
WH>
WH> Thanks for the patch!
WH>
WH> In order for it to go into 5.4 I'll need to get feedbac
Wes Hardaker wrote:
> In order for it to go into 5.4 I'll need to get feedback from other
> developers as well since we're in lock-down mode on that code branch.
> To me your patch looks good and like the right thing to do. To the
> other developers: please chime in if you agree (or not).
+1 (a b
> "RS" == Robert Story <[EMAIL PROTECTED]> writes:
RS> On Tue, 24 Oct 2006 09:02:52 -0700 Wes wrote:
WH> > "RS" == Robert Story <[EMAIL PROTECTED]> writes:
WH>
WH> RS> +1
WH>
WH> Point of order: I'm not sure Dave has actually said yes even thouh he
WH> posted the patches?
RS> I'm not su
> "AN" == Anthony Novatsis <[EMAIL PROTECTED]> writes:
AN> For Net-SNMP version 5.3.1 (sending a SIGTERM to the pass-through
AN> executable).
Thanks for the patch!
In order for it to go into 5.4 I'll need to get feedback from other
developers as well since we're in lock-down mode on that cod
> "AN" == Anthony Novatsis <[EMAIL PROTECTED]> writes:
AN> Firstly, is there any reason to make a difference between the errors that
AN> can be returned with pass and pass_persist in version 5.4?
Many times we include features that we receive patches for and though
ideally it would be nice if
On 25/10/06, Thomas Anders <[EMAIL PROTECTED]> wrote:
> Anthony Novatsis wrote:
> > Firstly, is there any reason to make a difference between the errors that
> > can be returned with pass and pass_persist in version 5.4?
> >
> > Secondly, is there any special reason why the full range of SNMPv2 err
Anthony Novatsis wrote:
> Firstly, is there any reason to make a difference between the errors that
> can be returned with pass and pass_persist in version 5.4?
>
> Secondly, is there any special reason why the full range of SNMPv2 error
> codes cannot be returned? From what I can see, it is fair
Dear All,In a Net-SNMP version 5.3.1 pass-through executable (either pass or pass_persist), it is only possible to return the errors wrongType(7) or notWritable(17) in response to a set request by writing the string "wrong-type" or "not-writable" respectively.
In version 5.4, I have seen in the sou
For Net-SNMP version 5.3.1 (sending a SIGTERM to the pass-through executable).*** net-snmp-5.3.1/agent/mibgroup/ucd-snmp/pass_persist.c Wed Oct 25 12:29:48 2006--- net-snmp-5.3.1.patched/agent/mibgroup/ucd-snmp/pass_persist.c Wed Oct 25 12:44:06 2006
** 767,772 --- 767,773
32 matches
Mail list logo
