Hi Eugen !
You are courageous an persistent ;-)
So some insights about how the server deals with schemas.
When you create the DefaultDirectoryServiceFactory() instance, it gets
'inited' at some point, and the initSchema() method is called:
in DefaultDirectoryServiceFactory:
public void init( String name ) throws Exception
{
if ( ( directoryService != null ) && directoryService.isStarted() )
{
return;
}
build( name );
...
private void build( String name ) throws Exception
{
directoryService.setInstanceId( name );
buildInstanceDirectory( name );
// Init the service now
initSchema();
...
and finally:
private void initSchema() throws Exception
{
File workingDirectory =
directoryService.getInstanceLayout().getPartitionsDirectory();
// Extract the schema on disk (a brand new one) and load the
registries
File schemaRepository = new File( workingDirectory, "schema" );
SchemaLdifExtractor extractor = new DefaultSchemaLdifExtractor(
workingDirectory );
try
{
extractor.extractOrCopy();
...
The key here is that we are going to fetch all files that match this
pattern in the file system (at least in the files that are resources):
".*schema[/\Q\\E]ou=schema.*\.ldif".
Either you have a system property that tells the server where to fetch
those files (schema.resource.location) or it defaults to the files that
are associated with the ResourceMap class loader (cl.getResources(
"META-INF/apacheds-schema.index" );)
FYI, this index is created while building the Apache LDAP API package,
using this maven plugin:
maven-antrun-plugin
generate-resources
value="target/generated-resources/apacheds/META-INF/apacheds-schema.index"
/>
value="src${file.separator}main${file.separator}resources${file.separator}"
/>
value="${line.separator}" />
token="${basedir}${file.separator}${schema.location}" value="" />
classifier="schema" type="index" />
run
(for the sake of completeness)
In any case, if you want to avoid processing this long list of files
(which is kind of costly), all you have to do is to set the
"schema.resource.location" system property that points to an empty
directory.
I'm not sure though that you won't need some part of the schemas for the
server to work properly, as we need to parse the DNs and the attributes
type within.
IMO, you should just get the minimal schema files (core, system), copy
them in the location you chose, to minimize the cost of loading the
schema at startup.
Side remark: up to a point, it would make sense to have a pre-loaded
schema based on the files, to avoid the parsing that is quite costly.
But that is an extension we have to include...
Hope it helps !
On 03/05/2022 02:27, Eugen Stan wrote:
Hi,
After a few hours of hacking at this I managed to get something working.
Thank you Emmanuel for your pointers.
I would like to improve startup time and avoid loading all (any of) the
schemas.
I am using DefaultDirectoryServiceFactory and LdapServer .
I replace the AuthenticatorInterceptor with my own.
I am able to run a simple ldap query and I log the username and passowrd:
ldapsearch -x -b "ou=system" -H ldap://localhost:10389 -D
"uid=admin,ou=system" -w secret
Using DefaultDirectoryServiceFactory loads all the schemas and does some
disk IO + starts slow.
Can I avoid loading the schemas and doing this much IO ?
I don't plan to use the schemas at all.
I gave it a shot but did not get far with that since
DefaultDirectoryService requires locks the disk and has some schema
initialization hardcoded inside - at specific paths.
I tink this logic could be made to be all in memory or to use a single
file but the code is too complex for me to figure out right now.
Thanks,
Eugen
For who is interested, the code is bellow (clojure) :
(ns ieugen.ldap-auth-provider.core
(:require [babashka.fs :as fs]
[taoensso.timbre :as log])
(:import (org.apache.directory.api.ldap.model.constants
AuthenticationLevel)
(org.apache.directory.server.core.api LdapPrincipal)
(org.apache.directory.server.core.api.interceptor.context
BindOperationContext)
(org.apache.directory.server.core.authn Authenticator)
(org.apache.directory.server.core.authn
