> On Jun 14, 2017, at 11:29 AM, Brian Brooks (US) <[email protected]> > wrote: > > In case it wasn't obvious from our pwdReset post, your hints last week about > setting ldap.server.type=openldap helped us get Fortress Rest 2.0.0-RC2 on > ApacheDS 2.0.0-M23 to return the user's locked and reset states.
That was a work-around, and not recommended as solution as there will prolly be some (other) problems in the apis you will encounter, when you call other methods, and they attempt some auditing operations. So, if you can use latest source, pull, and change the server type back to apacheds. If you can’t, add this flag to fortress.properties, which will disable going down code pathways specific to slapd auditing, which isn’t support on apacheds: disable.audit=true Later, when you upgrade to next release, you can remove the audit flag and simply use this: > ldap.server.type=apacheds > > To get it working we performed these steps: > 1. ApacheDS - deleted the JDBM partition and re-added. > 2. ApacheDS - deleted relevant entries. We found it strange that the entries > still had to be deleted after the partition was deleted. Don’t know the answer but could be a good question for directory users ML. > > 3. Fortress - Changed ldap.server.type from apacheds to openldap in > build.properties and re-ran mvn install. Hand-generated a final > fortress.properties. Copied this fortress.properties to the appropriate > locations under fortress-core, fortress-web, and fortress-enmasse. OK, but again, we’ll want to revert to apacheds, per earlier comments, when possible. > > 4. Fortress - Reinstalled the Fortress components (mvn install -Dload.file > calls) with the updated fortress.properties. > > It took a bit of time to re-install because we got stuck trying to understand > "ApacheDS & Fortress QUICKSTART", "SECTION 3. Apache Fortress Core Setup" > https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-APACHEDS.md#section-3-apache-fortress-core-setup. > In particular, "README for Apache Fortress Configuration Subsystem" > https://github.com/apache/directory-fortress-core/blob/master/README-CONFIG.md. > Even though we had ldap.server.type=openldap in fortress.properties, we > noticed the ldap.server.type getting loaded into cn=TOMCAT, > ou=Config,@SUFFIX@ by directory-fortress-core\ldap\setup\refreshLDAPData.xml > > <addconfig> > <config props="config.realm:TOMCAT"/> > <config props="authn.type:realm"/> > <config props="ldap.server.type:@SERVER_TYPE@"/> > > and started noticing that our fortress.properties settings were getting > overridden by cn=DEFAULT, ou=Config,@SUFFIX@. > Fortress config subsystem is described in some detail here: https://github.com/apache/directory-fortress-core/blob/master/README-CONFIG.md Don’t know if you’ve had a chance to read it yet. Please do, and send me your follow-up questions. The hope is this doc can walk users through much of what is needed to correctly use this system. I’ll use your feedback to improve the doc, and perhaps even the system, if we find it isn’t usable. > > It took a bit of time to re-install because we got stuck trying to understand > "ApacheDS & Fortress QUICKSTART", "SECTION 3. Apache Fortress Core Setup" > https://github.com/apache/directory-fortress-core/blob/master/README-QUICKSTART-APACHEDS.md#section-3-apache-fortress-core-setup. > In particular, "README for Apache Fortress Configuration Subsystem" > https://github.com/apache/directory-fortress-core/blob/master/README-CONFIG.md. > Even though we had ldap.server.type=openldap in fortress.properties, we > noticed the ldap.server.type getting loaded into cn=TOMCAT, > ou=Config,@SUFFIX@ by directory-fortress-core\ldap\setup\refreshLDAPData.xml > > <addconfig> > <config props="config.realm:TOMCAT"/> > <config props="authn.type:realm"/> > <config props="ldap.server.type:@SERVER_TYPE@"/> > > and started noticing that our fortress.properties settings were getting > overridden by cn=DEFAULT, ou=Config,@SUFFIX@. > > A couple of issues we dealt with specifically were: > > 1. Fortress Core - The relationship between > directory-fortress-core\config\fortress.properties and > directory-fortress-core\config\bootstrap\fortress.properties is unclear. We > ended up constructing a fortress.properties by appending most of the > config\bootstrap\fortress.properties contents to config\fortress.properties. Properties can reside in multiple locations per the config doc, but during initial load, they must only be in the fortress.properties file, because the ldap config node hasn’t been added yet. So you only need bootstrap to run the initial load, i.e. mvn install -Dload.file=./ldap/setup/refreshLDAPData.xml after which many of the properties will be loaded into the config node in ldap. Of course you don’t have to do this, you can just put everything in fortress.propertes if you like, as you found out. The rationale for the config node in ldap is described in the doc but basically allows centralization, but putting most props in one node as opposed to distributing widely across all agents, in properties files. For implementations that use the config node in ldap, the fortress.properties is much smaller, and mostly just contains the coordinates necessary to connect to the ldap server, where the rest of the props reside. > > 2. Fortress Rest - Loading FortressRestServerPolicy.xml seems to require > that the LDAP server contain cn=DEFAULT, ou=Config,@SUFFIX@ even if the > deployment plan is to rely only on fortress.properties. > > We tried to reinstall Fortress without any ou=Config entries but kept getting > failures during Fortress Rest installation That is a bug and should be fixed. If you want to open a JIRA ticket I’ll see what I can do. > > Finally, we settled on running c:\dev\directory-fortress-core>mvn install > -Dload.file=./ldap/setup/refreshLDAPData.xml with a hand-modified > refreshLDAPData.xml which creates a cn=DEFAULT, ou=Config,@SUFFIX@ with no > child entries: > > <addconfig> > <config props="config.realm:DEFAULT"/> > </addconfig> > > Thanks for your help and all the quick responses! You shouldn’t have to hand edit that file but I admire your determination in getting a working solution. Thanks, Shawn
