I must congratulate you on the research thus far. You are definitely on the
right track. As for documentation surrounding this subsystem, I must admit, is
a bit sparse. There are the sources you mentioned, but really nothing that
ties it all together.
I started a document, README-CONFIG.txt, in the root folder. Eventually it
needs to be massaged into a proper document. It is missing details, but we can
use it as a starting point to get this important aspect of the system
documented.
Here I have pasted it, and we can go from there:
_________________________________________________________________________________
###################################################################################
# README-CONFIG.txt for Fortress Core Identity and Access Management SDK
# Version 1.0-RC41
# This file contains an overview of the fortress configuration system.
_________________________________________________________________________________
###################################################################################
# SECTION 1. Overview
#################################################################################
Fortress obtains its configuration information from the following three sources:
1. fortress.properties file.
2. Java system properties
3. LDAP entry
Of the three listed, 1 is mandatory, 2 & 3 are optional. This means you may
copy everything into the fortress.properties
file and forgo the usage of the other two. The precedence is same order as
listed.
A. fortress.property file:
#################################################################################
The general idea is the property file contains the coordinates to locate the
config entry stored in LDAP.
B. Java system properties:
#################################################################################
The system properties are only there to allow external subsystems the ability
to poke properties in at runtime. A use case for #2 is a deployed war file,
i.e. fortress-web,
that is downloaded from the Internet and needs to have its ldap configuration
parameters overridden to point to proper location.
You can only change these values using the system properties, which are LDAP
connection coordinates to config LDAP entry:
fortress.host
fortress.port
fortress.admin.user
fortress.admin.pw
fortress.min.admin.conn
fortress.max.admin.conn
fortress.enable.ldap.ssl
fortress.enable.ldap.ssl.debug
fortress.trust.store
fortress.trust.store.password
fortress.trust.store.set.prop
fortress.config.realm
fortress.ldap.server.type
C. LDAP entry:
#################################################################################
The idea is to store most of the parameters inside the LDAP config node to cut
back on the number of places things must change.
The fortress configuration subsystem determines the location of the
configuration node using the following properties located
inside either fortress.properties, or overriden by system properties:
# This node contains fortress properties stored on behalf of connecting LDAP
clients:
config.realm=DEFAULT
config.root=ou=Config,dc=example,dc=com
The properties are stored inside the configuration node in name:value format.
You can view the config node of a
working fortress DIT to see what's there.
_________________________________________________________________________________
#################################################################################
# SECTION 2. How It Works
#################################################################################
The build.properties file is used by the fortress core ant script, build.xml,
to push attribute values into the following locations:
1. fortress.properties
2. refreshLDAPData.xml - this is the base load script that sets up the DIT
structure and populates the config node in LDAP
The fortress.properties are then loaded onto the classpath where it will be
found by fortress. The refreshLDAPData.xml is
the base load script that can be loaded using this command:a
# mvn install -Dload.file=./ldap/setup/refreshLDAPData.xml
Anytime you need to refresh the values contained inside the other files, run
this command:
# mvn install
This will then use the maven-antrun-plugin to kick off the following ant target
within the build.xml file:
<ant antfile="${basedir}/build.xml" target="init-fortress-config" />
Which then copies values from here:
fortress.properties.src
refreshLDAPData-src.xml
Replaces values inside the src file tokens @NAME@ with the corresponding value
found inside the build.properties.
For more info on which parameters are used where, look at the
init-fortress-config target located inside the build.xml file.
Shawn
> On Dec 2, 2015, at 3:43 PM, Jan Sindberg <[email protected]> wrote:
>
> I am looking at fortress.properties and build.properties. I am beginning to
> realize that some configuration is for initial setup of the base structure
> with the ant-script and a file such as refreshLDAP.xml
> I'm also looking at Javadoc in GlobalIds.java and trying to trace some of
> these.
> Until now I have seen the documentation on
> https://directory.apache.org/fortress/installation/apacheds.html and followed
> the ten minutes guide.
> Is there any more documentation which explains in a little more detail how I
> make this production ready?
> It occurs to me that the fortress.properties I am currently using in our
> test-environment doesn't even define suffix ... I was just about to say that
> I can't understand how that works, but then I realized that the config-tool
> initializes itself with values stored on the LDAP.
>
> # This node contains fortress properties stored on behalf of connecting LDAP
> clients:
> config.realm=DEFAULT
> config.root=ou=Config,dc=example,dc=com
>
> The (generated) config/bootstrap/fortress.properties is used when setting up
> the Fortress DIT and a config for one Fortress Host (or application).
> And the slimmed down config/fortress.properties contains what is needed at
> normal runtime.
> Well -- There I got a little closer :-)
> I probably wants to use different suffix for individual applications, but I
> can imagine that I probably don't want to mess with the rest of the Fortress
> DIT :-)
> Any good advices or documents I should read in order to become convincingly
> knowing and get the config production ready?
