reworked the config readme…

___________________________________________________________________________________
###################################################################################
# README-CONFIG.txt for Fortress Core Configuration Usage
# Version 1.0-RC41
# This file contains an overview of the fortress configuration system.
___________________________________________________________________________________
###################################################################################
# SECTION 1.  Fortress Configuration Subsystem Overview
###################################################################################

Fortress obtains all of its configuration settings from the following two 
locations:

___________________________________________________________________________________
A. Ant Property files - Seeds downstream fortress.properties, refreshLDAP.xml 
and slapd.conf files.
___________________________________________________________________________________

The ant property subsystem is fed using three files:
i.   user.properties  - optional, when found, located in user's home directory. 
 Properties found here take precedence over those following.
ii.  slapd.properties - optional, when found, located in root folder of the 
package.  These props override those found in the build.properties file.
iii. build.properties - this file is required and must be located in the root 
folder of the package.

The ant configuration task uses the values found above to seed the 
fortress.properties and the base ldap load script (refreshLDAPData.xml).
It can also be used to populate the slapd.conf (if needing to configure the 
openldap server to fortress specs).

___________________________________________________________________________________
B. Java System Properties - Optional - Used to override fortress properties at 
runtime.
___________________________________________________________________________________
These fortress properties may be overridden at runtime by setting as Java 
System Properties:
i.     fortress.host
ii.    fortress.port
iii.   fortress.admin.user
iv.    fortress.admin.pw
v.     fortress.min.admin.conn
vi.    fortress.max.admin.conn
vii.   fortress.enable.ldap.ssl
viii.  fortress.enable.ldap.ssl.debug
ix.    fortress.trust.store
x.     fortress.trust.store.password
xi.    fortress.trust.store.set.prop
xii.   fortress.config.realm
xiii.  fortress.ldap.server.type

___________________________________________________________________________________
###################################################################################
# SECTION 2.  Fortress Configuration Subsystem Targets
###################################################################################

The ant build property files used by the fortress build.xml ant script, pushes 
attribute values into:
A. fortress.properties - primary target.  Contains connection coordinates to 
the remote config node in ldap.
B. refreshLDAPData.xml - secondary target.  Used to populate an actual ldap 
config node.
C. slapd.conf - this is an optional target - only needed when configuring a new 
openldap server from scratch.

___________________________________________________________________________________
###################################################################################
# SECTION 3.  Precedence of Artifacts found in the Fortress Configuration 
Subsystem
###################################################################################

Fortress uses apache commons configuration system to manage its properties 
inside its Java runtime environment.
This subsystem has been hard wired to pick up properties in the following order:
A. fortress.properties file - found on the classpath of that name.
B. LDAP configuration node - found by config coordinates set in the 
fortress.properties file itself.
C. Java system properties - to override any of the 13 properties listed above.

These properties are mutable inside the fortress config subsystem which allows 
C's values to override B's to override A's.

___________________________________________________________________________________
###################################################################################
# SECTION 4.  More on Fortress properties
###################################################################################

The general idea is the fortress.properties are just enough to find the 
coordinates to locate an ldap entry on a remote server somewhere.
The fortress.properties file is picked off the runtime classpath during 
startup.  It then will read whatever is stored on the
remote server node in that config node for overrides, followed by those set as 
java system properties.

The remote server node's dn is constructed using fortress.property values:
config.realm=DEFAULT
config.root=ou=Config,@SUFFIX@

The above would be combined to create the dn:
ou=Config,dc=[whatever the suffix is]

Anytime you need to reinitialize the properties, the ldap config node and the 
DIT itself, re-run this command:
# mvn install

followed by:
# mvn install -Dload.file=./ldap/setup/refreshLDAPData.xml

If you are needing to make changes to an ldap system already in use, simply 
modify the values inside fortress.properties directly.  If the config
node must be changed, any general purpose ldapbrowser can be used to to mod its 
values.  Fortress also has apis to do this, ConfigMgr, for custom
program utilities.

More notes:
- Use caution when running the -Dload.file target with 'refreshLDAPData.xml' as 
that script also deletes all nodes the suffix before it reloads anew.
- Don't run refreshLDAPData.xml in production.
- There is nothing preventing you from putting all of the fortress properties 
inside the fortress.properties file and skipping the remote server step.
- We want to minimize the number of locations where the same data must be 
stored.  Imagine a network with hundreds, even thousands of fortress agents 
running.
- We don't need to replicate the same data everywhere which is where remote 
config nodes are used.
- Tailor these procedures to match your requirements.
- For more info on which parameters are used where, look at the 
init-fortress-config target located inside the build.xml file.

Shawn

Reply via email to