Re: 'Inter-Tables indexing' and perl

Quoting Dave Shield <[email protected]>:

> On Fri, 2005-10-14 at 14:21 +0200, Turbo Fredriksson wrote:
>
>> But if I understand you correctly, [the client table] should
>> be split into two tables, one with the client info and one
>> with the job name info?
>
> Yup.
> Everything at the same level of nesting can be grouped into the
> same table.  Different levels of nesting imply different tables.

Which kind'a make sence when you think about it (and told a litte
more how tables work <in SNMP> :). Thanx.

> SNMP (or strictly SMI) ordering is defined to walk tables in
> column-major order, rather than the (perhaps more natural)
> row-major order.   It does make sense when you think about
> walking the columns of a table in parallel
>    ("snmpgetnext stat1 stat2 stat3 stat4 stat5")
> rather than serially, but often comes as a surprise to those
> new to SNMP.

That I have to keep at hand and experiment with, because I
didn't _see_ it if you know what I mean...

> Walking an SNMP table would *not* (normally) display the index
> values.

That was a little of a surprise though. I was hoping it would...

I've only played with 'single table' SNMP so far, and this 'multi
table' stuff is a _lot_ more difficult and complicated. I can't
_see_ it be for me yet..

> Assuming that you have other information that you need to report
> about each client system (and about each individual named jobs),
> then walking either of these tables would only display this other
> information - not the client/jobName values (other than as part of
> the indexing for that table).
>
> I.e.:
>     $ snmpwalk clientTable
>     clientDescr.client1 = "Description of 'client1'"
>     clientDescr.client2 = "Description of 'client2'"
>     clientContact.client1 = "Poor sod in charge of 'client1'"
>     clientContact.client2 = "Poor sod in charge of 'client2'"

Yeah, that table was kinda 'quite simple' once I started to get
the theory in place. Making it in practise was a little more job
though. I naturaly made it the other way around. First all info
about client1 THEN all the info about client2. But i actually
(just before reading this mail) managed to _see_ 'the errors
of my ways' and got the table correct. Somewhat... There's a strange
bug somewhere...

----- s n i p -----
root@aurora:~# table OID_BASE.6
SNMP table: enterprises.bayourCom.snmp.baculaStats.baculaClientsTable

 baculaClientsIndex     baculaClientName                  baculaClientUname baculaClientAutoPrune baculaClientRetentionFile baculaClientRetentionJob
                  1                    ?                                  ?                     ?                         ?                        ?
                  2              client2 sparc-unknown-linux-gnu,debian,3.0                  true                   1209600                  2592000
                  3              client3       i386-pc-linux-gnu,debian,3.0                  true                   1209600                  2592000
                  4              client4 sparc-unknown-linux-gnu,debian,3.0                  true                   1209600                  2592000
root@aurora:~# walk OID_BASE.6
OID_BASE.6.1.1.1 = 1
OID_BASE.6.1.1.2 = 2
OID_BASE.6.1.1.3 = 3
OID_BASE.6.1.1.4 = 4
OID_BASE.6.1.2.1 = client1
OID_BASE.6.1.2.2 = client2
OID_BASE.6.1.2.3 = client3
OID_BASE.6.1.2.4 = client4
OID_BASE.6.1.3.1 = sparc-unknown-linux-gnu,debian,3.0
OID_BASE.6.1.3.2 = sparc-unknown-linux-gnu,debian,3.0
OID_BASE.6.1.3.3 = i386-pc-linux-gnu,debian,3.0
OID_BASE.6.1.3.4 = sparc-unknown-linux-gnu,debian,3.0
OID_BASE.6.1.4.1 = true(1)
OID_BASE.6.1.4.2 = true(1)
OID_BASE.6.1.4.3 = true(1)
OID_BASE.6.1.4.4 = true(1)
OID_BASE.6.1.5.1 = 1209600
OID_BASE.6.1.5.2 = 1209600
OID_BASE.6.1.5.3 = 1209600
OID_BASE.6.1.5.4 = 1209600
OID_BASE.6.1.6.1 = 2592000
OID_BASE.6.1.6.2 = 2592000
OID_BASE.6.1.6.3 = 2592000
OID_BASE.6.1.6.4 = 2592000
----- s n i p -----

For some reason the client1 isn't shown in the table!?
The full MIB is at http://www.bayour.com/Softwares/bind9-snmp/BAYOUR-COM-MIB.txt.

> (and similarly for the jobTable)
> If there isn't any other information required (at either level)
> then the corresponding table can be dropped, and the relevant index
> moved into the next table (but still defined as "not-accessible").
>
> So if you *just* need to report the statistics (and nothing else),
> then you'd end up with a single statsTable, defined (and
> simplified) somewhat as follows:
>
>     baculaStatsTable   OBJECT-TYPE
>        SYNTAX          SEQUENCE OF BaculaStatsEntry
>           :
>     ::= { baculaStats 4 }
>
>     baculaStatsEntry   OBJECT-TYPE
>        SYNTAX          BaculaStatsEntry
>        INDEX           { bCName, bJName, bJId }
>           :
>     ::= { baculaStatsTable 1 }
>
>     BaculaStatsEntry ::= SEQUENCE {
>         bCName         OCTET STRING,
>         bJName         OCTET STRING,
>         bJId           OCTET STRING,
>         stat1          OCTET STRING,
>           :
>         stat5          OCTET STRING
>     }
>
>     bCName             OBJECT-TYPE
>       MAX-ACCESS       not-accessible
>          :
>     ::= { baculaStatsEntry 1 }
>
>     bJName             OBJECT-TYPE
>       MAX-ACCESS       not-accessible
>          :
>     ::= { baculaStatsEntry 2 }
>
>     bJId               OBJECT-TYPE
>       MAX-ACCESS       not-accessible
>          :
>     ::= { baculaStatsEntry 3 }
>
>     stat1              OBJECT-TYPE
>       MAX-ACCESS       read-only
>          :
>     ::= { baculaStatsEntry 4 }
>
>               :
>
>     stat5              OBJECT-TYPE
>       MAX-ACCESS       read-only
>          :
>     ::= { baculaStatsEntry 8 }

Hmmm. I assume 'bCName' is the client name from the client table,
'bJName' is the job name from the job (name) table and 'bJId'
is the job ID from the job ID table... But shouldn't there be an
index/entry for the stats table as well?

Hm, can't be it. It seems like you only have _ONE_ table here,
with the client name, job name and job ID _in addition_ to the
statistics...

> Have I managed to confuse you again?

Yes. You destroyed the last shread of thought that i understood
indexing :).

When I created my (first) MIB (the one for Bind9), I looked a lot
at the IF-MIB. That 'outputted' a bunch of numbers which was what
I thought was the index. But now I see that I can skip that part
all together and use the one I originialy WANTED to use - the
client name, job name and job ID.

Those numbers was superfluous any way, I just thought I needed
it to do tables...

This will/would simplify the script quite a lot... Seeing you
wing up a MIB in no time (correctly :) makes 'all the pieces
fall into place'... Most of them any way.

Can't thank you enough for the help. Much appreciated!
-- 
ammonium quiche ammunition SEAL Team 6 Marxist Legion of Doom NORAD
supercomputer Kennedy pits $400 million in gold bullion Khaddafi
Semtex smuggle Uzi
[See http://www.aclu.org/echelonwatch/index.html for more about this]
[Or http://www.europarl.eu.int/tempcom/echelon/pdf/rapport_echelon_en.pdf]
If neither of these works, try http://www.aclu.org and search for echelon.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users