<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Non-member submission from Fotis Georgatos gef@localhost


---------- Forwarded message ----------
Date: 21 Feb 2002 23:22:27 -0000
From: owner-tt-wg@localhost
To: tt-ops@localhost
Subject: An example LDAP schema for Test Traffic

Hi to all (experimenters among us),

In order to get a good grisp on LDAP ins and outs, I wrote a few case solutions.

This one assumes a Test Traffic project, in which you don't require
the history of state changes (this is possible, with a few additions).
There are examples in the comments eg. how to list all machines which are "ON".

About LDAP:
LDAP is in principle a database, optimized for reads rather than writes.
It is good for directory-like information and has nice interoperability,
with multiple "COTS" clients and replication abilities.
On the other hand, it is very ISO influenced, carrying the messy OID culture
which is equally found within SNMP protocol. Still, it works just fine.
See below for yourself.

Enjoy,
Fotis


# TTraffic Object Schema
# $OpenLDAP$
#
#                                                        Fotis Georgatos
#                                                          February 2002
#
#
#      Schema for Representing TTraffic Objects in a LDAP Directory
#
# Status of this Memo
#
#    This memo provides information for the Internet community.  It does
#    not specify an Internet standard of any kind.  Distribution of this
#    memo is unlimited.
#
# Abstract
#
#    This document defines an example schema for representing systems
#    like the ones used in the Test Traffic Measurement project / RIPE NCC
#    See for more: http://www.ripe.net/test-traffic/
#    This schema can be used for other applications with similar requirements
#
#
#
# How to install (if you don't know how to setup LDAP, there is a FAQ)
#
#    a) copy this file to /etc/openldap/schema/ttraffic.conf
#    b) add the following line to /etc/openldap/slapd.conf , after "include"s:
#       include		/etc/openldap/schema/ttraffic.conf
#    c) restart LDAP daemon, this is all
#
# How to use
#
#    Any LDAP client tool:
#    * /usr/bin/ldap* command line tools
#    * GQ LDAP X11 graphical front-end
#    * web2ldap
#    * Python, Perl hooks for LDAP etc
#
# Examples
#
#    $ ldapsearch -x "(objectclass=ttHost)"
#    $ ldapsearch -x "(objectclass=ttHost)" ttStatus
#    $ ldapsearch -x -LLL "(&(objectclass=ttHost)(ttStatus=ON))" cn
#
# Note on OIDs:
#    You can get your own 1.3.6.1.4.x-like MIB space, by requesting so from IANA.
#    And do not use the following MIBs in public experiment configurations!

attributetype ( 1.3.6.1.4.12158.1.2
        NAME 'ttidNumber'
        DESC 'An integer uniquely identifying a testbox in an administrative domain'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.12158.1.3
        NAME 'ttStatus'
        DESC 'Expected status of a testbox, can be ON,OFF,SETUP, etc'
        EQUALITY caseExactMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE )

attributetype ( 1.3.6.1.4.12158.1.4
        NAME 'OldIPHostNumbers'
        DESC 'former IP addresses as a dotted decimal, eg. 192.168.1.1'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{128} )

# cn holds the name of a system, like "tt01"
# businessCategory is a logical group that the system belongs, eg. groupA,B,C
# ou & c are good to store location for a machine, c is ISO639 country code
# cNAMERecord holds a DNS alias, if available
# organizationalPerson can hold a contact reference
# l holds the GPS coordinates; you can always tell an l from an 1 or an I, hm? ;-)

objectclass ( 1.3.6.1.4.12158.1.1
        NAME 'ttHost'
        SUP top
        AUXILIARY
        DESC 'Abstraction of a TTM host.'
        MUST ( ttidNumber $ cn $ ipHostNumber $ ttStatus $ businessCategory )
        MAY ( OldipHostNumbers $ l $ description $ ou $ c $ cNAMERecord $ createTimestamp $ modifyTimestamp) )





<<< Chronological >>> Author    Subject <<< Threads >>>