Why you should stay clear of REST

Pro Documentum

Once again I get inspired by to write this blogpost by Alvaro de Andres Documentum 16.3 delayed until Feb 2018 blogpost – there is some “interesting discussion” about REST where you can find following opinion from another member of talented team:

Is DFS a personal target for your projects? Baseline REST is a mature offering and it has active Engineering working on it. The planet seems to be focused on a RESTful interface and the DCTM platform is meeting that focus with a set of platform APIs. As I’m sure you are aware Captiva, xCP and D2 can be access through REST interfaces.

Actually, it is not clear what Tomas meant under the word “REST” because my observations about REST are following:

  • when most people talk about REST they typically mean JSON, which is obviously wrong: it is true that in the most cases (especially when REST client is…

View original post 639 more words

Fighting with DEV ENV. Part II

It seems that talented team decided to move/upgrade JMS from JBossAS to WildFly even in 7.2 release:

Below is an adapted config for DEV ENV:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<server xmlns="urn:jboss:domain:3.0">
    <extensions>
        <extension module="org.jboss.as.deployment-scanner" />
        <extension module="org.jboss.as.ee" />
        <extension module="org.jboss.as.naming" />
        <extension module="org.jboss.as.remoting" />
        <extension module="org.jboss.as.security" />
        <extension module="org.wildfly.extension.io"/>
        <extension module="org.wildfly.extension.undertow" />
    </extensions>

    <profile>
        <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
            <deployment-scanner deployment-timeout="300" path="deployments" relative-to="jboss.server.base.dir" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}" scan-interval="5000" />
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:ee:3.0" />
        <subsystem xmlns="urn:jboss:domain:io:1.1">
            <worker name="default"/>
            <buffer-pool name="default"/>
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:naming:2.0">
            <remote-naming />
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:remoting:3.0" />
        <subsystem xmlns="urn:jboss:domain:security:1.2" >
            <security-domains>
                <security-domain name="other" cache-type="default">
                    <authentication>
                        <login-module code="Remoting" flag="optional">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                        <login-module code="RealmDirect" flag="required">
                            <module-option name="password-stacking" value="useFirstPass"/>
                        </login-module>
                    </authentication>
                </security-domain>
            </security-domains>
        </subsystem>
        <subsystem xmlns="urn:jboss:domain:undertow:2.0">
            <buffer-cache name="default" />
            <server name="default-server">
                <http-listener max-post-size="0" name="default" redirect-socket="https" socket-binding="http" />
                <host alias="localhost" name="default-host">
                    <location handler="welcome-content" name="/" />
                    <filter-ref name="server-header" />
                    <filter-ref name="x-powered-by-header" />
                </host>
            </server>
            <servlet-container name="default">
                <jsp-config />
                <websockets />
            </servlet-container>
            <handlers>
                <file name="welcome-content" path="${jboss.home.dir}/welcome-content" />
            </handlers>
            <filters>
                <response-header header-name="Server" header-value="WildFly/9" name="server-header" />
                <response-header header-name="X-Powered-By" header-value="Undertow/1" name="x-powered-by-header" />
            </filters>
        </subsystem>
    </profile>

    <interfaces>
        <interface name="public">
            <inet-address value="${jboss.bind.address:0.0.0.0}" />
        </interface>
    </interfaces>

    <socket-binding-group default-interface="public" name="standard-sockets" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="ajp" port="9089" />
        <socket-binding name="http" port="9080" />
        <socket-binding name="https" port="9082" />
    </socket-binding-group>
</server>

Setup dfc.properties properly

Can’t stop catching myself thinking about JMS high availability misfeature, or more precisely: why it is supported by workflow methods only, and it seems that all CS instances are just misconfigured. Let’s explain.

Below is a brand new CS installation, which already has one dm_client_rights record:

Connected to Documentum Server running Release 7.3.0050.0039  Linux64.Postgres
Session id is s0
API> ?,c,select r_object_id, client_id from dm_client_rights
r_object_id       client_id                               
----------------  ----------------------------------------
0802994680000582  dfc_xxpa7jhtGFkRfHvrQmUIyaffxlka        
(1 row affected)

API> dump,c,0802994680000582
...
USER ATTRIBUTES

  object_name                     : dfc_docu73dev01_ffxlka
  title                           : 
  subject                         : 
  authors                       []: <none>
  keywords                      []: <none>
  resolution_label                : 
  owner_name                      : dmadmin
  owner_permit                    : 7
  group_name                      : docu
  group_permit                    : 1
  world_permit                    : 1
  log_entry                       : 
  acl_domain                      : dmadmin
  acl_name                        : dm_4502994680000222
  language_code                   : 
  client_id                       : dfc_xxpa7jhtGFkRfHvrQmUIyaffxlka
  public_key_identifier           : 77016FB9066276A0EF4801918F27F52C7176CD2F
  host_name                       : docu73dev01
  allowed_roles                 []: <none>
  allow_all_roles                 : T
  allow_all_priv_modules          : F
  principal_auth_priv             : T
  server_trust_priv               : T
  app_name                        : 
  is_globally_managed             : F

Where did this dm_client_rights record come from? According to the log file $DM_HOME/install/logs/install.log this dm_client_rights record was created by installer:

10:25:56,168  INFO [main] com.documentum.install.server.installanywhere.actions.DiWAServerCreateBofRegistryUser - Registering Client Roles.
10:25:56,198  INFO [main] com.documentum.fc.client.security.impl.JKSKeystoreUtilForDfc - keystore file name is /u01/documentum/cs/shared/config/dfc.keystore
10:25:56,382  INFO [main] com.documentum.fc.client.impl.connection.docbase.DocbaseConnection - Object protocol version 2
10:25:56,818  INFO [main] com.documentum.fc.client.security.impl.JKSKeystoreUtilForDfc - keystore file name is /u01/documentum/cs/shared/config/dfc.keystore
10:25:56,844  INFO [main] com.documentum.fc.client.security.impl.DfcIdentityPublisher - found client registration: false
10:25:57,148  INFO [main] com.documentum.fc.client.privilege.impl.PublicKeyCertificate - stored certificate for CN 
10:25:57,272  INFO [main] com.documentum.fc.client.security.impl.IpAndRcHelper - filling in DCTM_PSQL a new record with this persistent certificate:
-----BEGIN CERTIFICATE-----
MIIDHzCCAgcCEDM7pl2LftisOKZ3mYFjNigwDQYJKoZIhvcNAQELBQAwTjETMBEG
A1UECwwKRG9jdW1lbnR1bTEMMAoGA1UECgwDRU1DMSkwJwYDVQQDDCBkZmNfeHhw
YTdqaHRHRmtSZkh2clFtVUl5YWZmeGxrYTAeFw0xNzAzMTExMDEyMDVaFw0yNzAz
MDkxMDE3MDVaME4xEzARBgNVBAsMCkRvY3VtZW50dW0xDDAKBgNVBAoMA0VNQzEp
MCcGA1UEAwwgZGZjX3h4cGE3amh0R0ZrUmZIdnJRbVVJeWFmZnhsa2EwggEiMA0G
CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDPY3I1TzGodyI7Q7oHuLlA4N0IdLnp
oUEZqONy5Ev1f8RJLIJGowjSQme1HPrk6ZgdyBlGkLqguRdnn6hLrBIUiZSc7XRr
OM8xCYp6wEXUuxDTpX58Q32QLInjTjftHOblav201lOQStQUcrEAcUVZ+UK/Xt1t
Q9hQUpOvXWDRxBRPpN7VdTg1lCNuNC/BjYO/yBc2zUPYsarmnM1BcyeTi6RmlfME
PUsVPMqS8muBKP/o7ZUqXVMWNFNRHVbnOCX8KHZgO4DQLp7pcgYq0ak4vQ6BEfx8
fxo/egAS84JiemOxhslxytN5cBnFmc3NCdKKVzRcZE9fecC3DMt41dYfAgMBAAEw
DQYJKoZIhvcNAQELBQADggEBAARMI7W7ggw9GJZtfsqre5+idsfcxtuMPhI+bmU/
gAb3pyZug11z29AvCcprh545agcUQgm9wlgaJFUtiktd4n6hE12G46Vu/boqxy4J
iBs3kWQd2Qeh4Qobm8xvBu0VKSiHJRmbm5xslnq3yJorBZiNjvuoFVsaYtY24kiy
AxUB5y2vgUhZeLe+0WPrBEA3/I+ciGO/Jk6KXyL9vz8+04Hx6sBfkMsY1l8aa1HH
PtQdgfasysgVkIqCZ70zAXd5ARC4CXEwfhj6v/eq7X3CM4KCP4TiPqmzzapsLPn3
i0Or+fnwrOy/rYybndj0pgpnCbtinUZ7ZXmVtWDevMWey/Q=
-----END CERTIFICATE-----
10:25:57,280  INFO [main] com.documentum.fc.client.security.impl.DfcIdentityPublisher - found client registration: false
10:25:57,659  INFO [main] com.documentum.fc.client.security.impl.IpAndRcHelper - filling a new registration record for dfc_xxpa7jhtGFkRfHvrQmUIyaffxlka
10:25:57,672  INFO [main] com.documentum.fc.client.security.impl.DfcIdentityPublisher - [DFC_SECURITY_GR_REGISTRATION_PUBLISH] this dfc instance is now published in the global registry DCTM_PSQL
10:25:57,695  INFO [main] com.documentum.fc.client.security.impl.DfcRightsCreator - assigning rights to all roles for this client on DCTM_PSQL
10:25:57,701  INFO [main] com.documentum.fc.client.security.impl.DfcRightsCreator - found client rights: false
10:25:57,733  INFO [main] com.documentum.fc.client.security.impl.DfcIdentityPublisher - found client registration: true
10:25:57,746  INFO [main] com.documentum.fc.client.security.impl.DfcRightsCreator - found client rights: false
10:25:57,989  INFO [main] com.documentum.fc.client.security.impl.IpAndRcHelper - filling a new rights record for dfc_xxpa7jhtGFkRfHvrQmUIyaffxlka
10:25:58,015  INFO [main] com.documentum.fc.client.security.impl.DfcRightsCreator - [DFC_SECURITY_DOCBASE_RIGHTS_REGISTER] this dfc instance has now escalation rights registered with docbase DCTM_PSQL

How many dfc.keystore files do we have?

~]$ find /u01/documentum/cs/ -name dfc.keystore
/u01/documentum/cs/shared/config/dfc.keystore
.../ServerApps.ear/APP-INF/classes/dfc.keystore
.../com.emc.ide.external.dfc_1.0.0/documentum.config/dfc.keystore

How many dfc.properties files do we have?

~]$ find /u01/documentum/cs/ -name dfc.properties
/u01/documentum/cs/shared/config/dfc.properties
.../ServerApps.ear/APP-INF/classes/dfc.properties
.../com.emc.ide.external.dfc_1.0.0/documentum.config/dfc.properties

You might say the second one (JMS’s) is not actually dfc.properties because it looks like:

#include /u01/documentum/cs/shared/config/dfc.properties
dfc.bof.classloader.enable_extension_loader_first=false

but it is, moreover dfc.config.file read-only property defines the path to dfc.properties file, and dfc.config.dir read-only property defines the directory containing dfc.properties file. Now, the only option which default value depends on dfc.config.dir is:

# Fully qualified file name of the keystore file holding the PKI credentials for 
# DFC. 
# 
# Defaults to dfc.keystore in the same directory where the property file 
# (dfc.properies) is found.                                                     
# 
dfc.security.keystore.file = ${dfc.config.dir}/dfc.keystore

I think it is obvious that $DOCUMENTUM_SHARED/config/dfc.properties is misconfigured because it lacks dfc.security.keystore.file entry.