directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <smckin...@apache.org>
Subject Re: Configuration
Date Thu, 03 Dec 2015 01:41:06 GMT
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 <jsi@autorola.com> 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?


Mime
View raw message