directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <enriqu...@gmail.com>
Subject Re: Configuration objectclass
Date Tue, 23 May 2006 15:06:34 GMT
John E. Conlon wrote:
> Experimenting with the OSGi Configuration Admin implementation in
> Enirique's sandbox/configuration.  Was able to upgrade it to use the
> felix service binder and interact with the latest SNAPSHOT apacheds/mina
> modules that I OSGi bundlized last week.  (Note: I haven't migrated to
> the bundles Enrique committed in the trunks/apacheds/osgi yet.)
> Nevertheless the cm bundle appears to be up, listening to the DIT for
> events, and offering it's Service for client bundle configuration. 
> 
> Next step is to add a configuration objectclass entry to the DIT so I
> can actually store configurations. Is there a configuration schema
> and/or a ConfigurationSchema.java for doing this?

Damn, I had a huge reply explaining this last night and Thunderbird 
flashed-out - it's never done that before.  Here it is again.

*** Keep in mind we agreed here, some time ago, to update these services 
to OSGi R4 and to move them to Felix, so the SVN location will change.

The short answer is that the attributesType's and objectClass's you are 
looking for are in the apache.schema.  We've typically put entries in 
the apache.schema until such time as there are enough of them to either 
warrant their own schema file or they justify their own OID range.

The standard location for configuration in the DIT is under 
ou=configuration,ou=system.  There should be this ou already, by default.

The apacheServiceConfiguration and the apacheFactoryConfiguration 
correspond to ManagedService's and ManageServiceFactory's, respectively. 
  You use these in conjunction with ExtensibleObject objectClass's to 
provide custom attributes.

Looking this over now, I would change apacheServiceConfiguration and 
apacheFactoryConfiguration from STRUCTURAL objectClass's to AUXILIARY 
objectClass's.  Then you could use them as "marker" objectClass's and 
add them to any DIT entry you so choose.  CM is going to return a set of 
attributes, so the objectClass doesn't matter and I think this would 
work and be more flexible.  I would still start searches below 
ou=configuration,ou=system.  WDYT?

I've included an example LDIF, below, of using this with the DNS 
service.  Using a ManagedServiceFactory is the natural way to handle 
multi-homed configurations, where you want to serve 1..n DIT locations 
to a specific NIC.  A DNS spec uses the term "catalog":

 From RFC 1035:

"... The catalog structure can be an almost static structure that
      need change only when the system administrator changes the
      zones supported by the server. ..."

Example showing use with a DNS Server Factory:

dn: cn=org.apache.dns.1,cn=dns,ou=services,ou=configuration,ou=system
objectClass: apacheServiceConfiguration
objectClass: extensibleObject
cn: org.apache.dns.1
ipAddress: 192.168.0.1
ipPort: 53
baseDn: dc=example,dc=com
apacheServicePid: org.apache.dns.1
apacheServiceFactoryPid: org.apache.dns.factory


Relevant entries in the apache.schema:

attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.15
     NAME 'apacheServicePid'
	DESC 'A string up to 256 characters in length'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )

attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.16
     NAME 'apacheServiceFactoryPid'
	DESC 'A string up to 256 characters in length'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} SINGLE-VALUE )

objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.3
     NAME 'apacheServiceConfiguration'
     SUP top
     STRUCTURAL
     MUST ( cn $ apacheServicePid )
     MAY ( apacheServiceFactoryPid ) )

objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.4
     NAME 'apacheFactoryConfiguration'
     SUP top
     STRUCTURAL
     MUST ( cn $ apacheServicePid ) )

Enrique


Mime
View raw message