[TriLUG] LDAP schema question

[Aaron S. Joyner]

Ryan Leathers wrote:

>This is not a "how do I make slapd work" question.
>I'm confused about how to align the data I care about with a schema.
>
>When do you write your own schema?  Can you get away with stuffing data
>into existing schema attributes even though it might not be a perfect
>fit?
>
>Let me explain...
>
>I have a lab reservation system.  It reserves groups of resources at a
>time.  We call these groups of resources pods.  In the LDAP schema,
>there is already an OU for each pod, and when the reservation is set up,
>the user's login is placed under that OU. 
>
>What we want to do is to store several application objects that
>represent the commands (Linux command lines) pointing to all the
>resources represented by the pod.  
>
>We know how to create a flat file for this, query it, and construct the
>user’s portal interface that way.  We'd prefer to use LDAP to store the
>application objects instead.  Since the application information for a
>pod is static, LDAP is ideally suited to hold it, performance-wise.
>
>An example of this might be:
>
>Pod P1 has three devices D1, D2, D3
>It also has three applications A1, A2, A3  
>Application A1 is invoked as connectTelnet –pod P1 –device D1
>Application A2 is invoked as connectTelnet –pod P1 –device D2
>Application A3 is invoked as connectTelnet –pod P1 –device D3
>
>So what needs to be stored is the pod OU P1, and under it, three
>applications called A1, A2 and A3 respectively, each containing its own
>command line and possibly some descriptive text, though that would not
>be strictly necessary.
>
>
>Now here is where we are unsure of how to proceed...
>
>LDAP schemas already have an applicationEntity object, but this seems to
>be an X.500 specific schema for an OSI layer 7 application.  As such,
>the simple Unix command line I am trying to use to represent
>applications, might not fit... or does it?  The fear is, if we try and
>use this in error, it may collide with some other future LDAP-based
>system, or it may be misinterpreted by someone in the future as a true
>OSI application entity and just cause confusion.
>
>The question is: does the applicationEntity object have any potential
>for use here, or is there a schema designed to support the “command
>line” type of application object fitting what is described above?
>
>Should we create a custom LDAP schema? I'd like to avoid that unless its
>truly necessary.
>
>If we don't decide on the right way to do this in LDAP soon, we may just
>build this in a flat file as it seems the simplest way to go with no
>room for unforeseen troubles down the road.
>
>Thanks in advance for your input
>
>Ryan
>
>  
>
(I'm being terse because I know a lot about Ryan's application, and I 
don't suspect this will be useful to a lot of people, thus I don't need 
to explain in full here.)

Don't use applicationEntity, that requires presentationAddress, and for 
all the reasons you listed is messy.

Do create your own schema entry for this, it's not too bad.  First off, 
you really should acquire an OID of your very own (it's shiny and the 
ladies like it).  Head over here to do it right:
http://www.iana.org/cgi-bin/enterprise.pl

If you're not interested in doing it right, or for testing in the mean 
time, you can cheat and use the 1.1. branch as it's not used for 
anything other than examples and by lazy people (to mortals reading 
this, this is *really* bad form to use in anything other than testing, 
please don't abuse this as it will bite you, and may bite someone who 
comes after you, too).  My examples will use the 1.1.2 branch, as does 
the TriLUG glue schemas I think I've talked about on the list before, 
that had to be put together when I migrated the cluster from openldap 
1.something.old to 2.something.newer (hopefully this hasn't bitten, and 
won't bite, the nice people who came after me :) ).

Something like this would be ideal:
attributetype ( 1.1.2.5.1
        NAME 'applicationCommand'
        DESC 'Full path to be executed to run an application'
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
        SINGLE-VALUE )

The SYNTAX oid given above is the valid syntax for a directory-path 
style entry (you're welcome).  I just snarfed it from the cron.schema, 
by grep'ing for 'command'.  You'll then of course want to make this 
attribute available by creating an objectClass which requires it:

objectclass ( 1.1.2.6.1
	NAME 'applicationType'
	SUP top
	STRUCTURAL
	MUST ( applicationCommand )


Depending on what for / where you're using these objects, you may / may 
not want it to be a child of 'top' and be structural. I trust you can 
tackle that part, if you get stumped just shout for help.

Aaron S. Joyner