Quantcast
Channel: Archives des Documentum - dbi Blog
Viewing all 173 articles
Browse latest View live

Documentum – Change password – 6 – CS/FT – JKS

$
0
0

Just like for the JBoss Admin password (here), this blog will be for both Content Servers and Full Text Servers. I will provide commands below to change the passwords of the Java KeyStore for the Java Method Server (JMS) and Full Text Servers (Dsearch/IndexAgent). Again, JKS aren’t only used in the scope of Documentum so if you are here for the JKS and not for Documentum, that’s fine too ;).

 

The steps are exactly the same for all JKS files, it’s just a matter of integrating that inside Documentum. Therefore, I will continue to use the JMS for single JKS update and I will use the Dsearch/IndexAgent for multiple updates. The steps are pretty simple:

  1. Store the current and new password in variables
  2. Backup the old configuration and JKS files
  3. Update the JKS password
  4. Restart the components
  5. Verify that the components are running over https

 

I. JMS Java KeyStore

For the JMS Java KeyStore, you obviously need to connect to all Content Servers and then perform the steps. Below, I’m using a JKS named “my.keystore” which is placed right next to the standalone.xml file. So let’s do that:

[dmadmin@content_server_01 ~]$ read -s -p "Please enter the CURRENT JKS password: " currentpw; echo
Please enter the CURRENT JKS password:
[dmadmin@content_server_01 ~]$ read -s -p "Please enter the NEW JKS password: " newpw; echo
Please enter the NEW JKS password:
[dmadmin@content_server_01 ~]$ read -p "Please enter the name of the JKS file with extension: " jks_name
Please enter the name of the JKS file with extension: my.keystore
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ cd $DOCUMENTUM_SHARED/jboss7.1.1/server/DctmServer_MethodServer/configuration/
[dmadmin@content_server_01 ~]$ cp ${jks_name} ${jks_name}_bck_$(date +"%Y%m%d-%H%M%S")
[dmadmin@content_server_01 ~]$ cp standalone.xml standalone.xml_bck_$(date +"%Y%m%d-%H%M%S")
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ keytool -storepasswd -keystore ${jks_name} -storepass ${currentpw} -new ${newpw}
[dmadmin@content_server_01 ~]$ keytool -keypasswd -keystore ${jks_name} -storepass ${newpw} -alias jms_alias -keypass ${currentpw} -new ${newpw}
[dmadmin@content_server_01 ~]$

 

These last two commands are the ones updating the Java KeyStore and the key passwords. In case your JKS and its included key do not have the same password, you will have to use the real passwords at the end of the second line. If the last command (the 2nd keytool command) is working, it means that you changed the JKS password properly in the first keytool command because you are now able to change the key password using the new JKS password (-storepass ${newpw}). Still following me?

Once this has been done, the next step is simply to update the password in the JMS configuration file and restart the JMS:

[dmadmin@content_server_01 ~]$ grep "password=" standalone.xml
                <ssl name="https" password="Old_JKS_Password" certificate-key-file="$DOCUMENTUM_SHARED/jboss7.1.1/server/DctmServer_MethodServer/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ sed -i 's,\(<[sk][se][ly].*password="\)[^"]*,\1'${newpw}',' standalone.xml
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ grep "password=" standalone.xml
                <ssl name="https" password="New_JKS_Password" certificate-key-file="$DOCUMENTUM_SHARED/jboss7.1.1/server/DctmServer_MethodServer/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ cd $DOCUMENTUM_SHARED/jboss7.1.1/server
[dmadmin@content_server_01 ~]$ ./stopMethodServer.sh
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ nohup ./startMethodServer.sh >> nohup-JMS.out 2>&1 &
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ sleep 30
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ curl -k -D - https://localhost:9082/DmMethods/servlet/DoMethod; echo
HTTP/1.1 200 OK
Content-Length: 144
Date: Sat, 22 Jul 2017 09:58:41 GMT
Server: MethodServer

<html><title>Documentum Java Method Server</title><body><font face="Verdana, Arial" size="-1"><p>Documentum Java Method Server</p></body></html>
[dmadmin@content_server_01 ~]$

 

If the password of the JKS has been changed properly for the JKS file as well as in the configuration file, then you should get an HTTP 200 OK return code.

 

II. Dsearch/IndexAgent Java KeyStores

For the Dsearch/IndexAgent Java KeyStores, you obviously need to connect to all Full Text Servers and then perform the steps again. Below, I’m using a JKS named “my.keystore”. It doesn’t matter where this file is placed since the commands below will anyway just find them. However, by default this file will be placed right next to the standalone.xml file: this is the default setup if you used the “ConfigSSL.groovy” script to setup the xPlore in SSL (see this blog for information about that and a lot of other of my blogs to see issues related to this script/setup in SSL). These commands are adapted in case you have several IndexAgents installed. Please note that the commands below will set the same JKS password for all JBoss instances (all Dsearch/IndexAgents). Therefore, if that’s not what you want (if you have Subject Alternative Names for example), you will have to execute the commands for each keystore, one by one.

[xplore@full_text_server_01 ~]$ read -s -p "Please enter the CURRENT JKS password: " currentpw; echo
Please enter the CURRENT JKS password:
[xplore@full_text_server_01 ~]$ read -s -p "Please enter the NEW JKS password: " newpw; echo
Please enter the NEW JKS password:
[xplore@full_text_server_01 ~]$ read -p "Please enter the name of the JKS file with extension: " jks_name
Please enter the name of the JKS file with extension: my.keystore
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name ${jks_name}`; do cp ${i} ${i}_bck_$(date +"%Y%m%d-%H%M%S"); done
[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name standalone.xml`; do if [[ ${i} != */template/* ]]; then cp ${i} ${i}_bck_$(date +"%Y%m%d-%H%M%S"); fi; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name ${jks_name}`; do keytool -storepasswd -keystore ${i} -storepass ${currentpw} -new ${newpw}; done
[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name ${jks_name}`; do keytool -keypasswd -keystore ${i} -storepass ${newpw} -alias ft_alias -keypass ${currentpw} -new ${newpw}; done
[xplore@full_text_server_01 ~]$

 

At this point, all the Java KeyStore have been backed up and updated and the related standalone.xml files have been backed up too. The only remaining step is to replace the passwords in the standalone.xml files, restart the components and test again the availability of the xPlore components:

[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name standalone.xml`; do if [[ ${i} != */template/* ]]; then grep "password=" ${i}; fi; done
                <ssl name="https" password="Old_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_PrimaryDsearch/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
                <ssl name="https" password="Old_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_Indexagent_DocBase1/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
                <ssl name="https" password="Old_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_Indexagent_DocBase2/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
                <ssl name="https" password="Old_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_Indexagent_DocBase3/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name standalone.xml`; do if [[ ${i} != */template/* ]]; then sed -i 's,\(<[sk][se][ly].*password="\)[^"]*,\1'${newpw}',' ${i}; fi; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `find $XPLORE_HOME -name standalone.xml`; do if [[ ${i} != */template/* ]]; then grep "password=" ${i}; fi; done
                <ssl name="https" password="New_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_PrimaryDsearch/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
                <ssl name="https" password="New_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_Indexagent_DocBase1/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
                <ssl name="https" password="New_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_Indexagent_DocBase2/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
                <ssl name="https" password="New_JKS_Password" certificate-key-file="$XPLORE_HOME/jboss7.1.1/server/DctmServer_Indexagent_DocBase3/configuration/my.keystore" cipher-suite="TLS_RSA_WITH_AES_128_CBC_SHA"/>
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server
[xplore@full_text_server_01 ~]$ for i in `ls stop*.sh`; do ./${i}; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ nohup ./startPrimaryDsearch.sh >> nohup-PrimaryDsearch.out 2>&1 &
[xplore@full_text_server_01 ~]$ for i in `ls startIndexag*.sh`; do ia=`echo $i|sed 's,start\(.*\).sh,\1,'`; nohup ./$i >> nohup-$ia.out 2>&1 &; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sleep 30
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ curl -k -D - https://localhost:9302/dsearch/; echo
HTTP/1.1 259
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 UTC
Content-Type: text/html;charset=UTF-8
Content-Length: 65
Date: Sat, 22 Jul 2017 11:33:38 GMT

The xPlore instance PrimaryDsearch [version=1.5.0020.0048] normal
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ for i in `ls -d DctmServer_Indexag*`; do port=`grep '<socket-binding .*name="https"' ./${i}/configuration/standalone.xml|sed 's,.*port="\([0-9]*\).*,\1,'`; echo; echo "  ** Accessing IndexAgent URL of '${i}' (${port})"; curl -k -D - https://localhost:${port}/IndexAgent; done

  ** Accessing IndexAgent URL of 'DctmServer_Indexagent_DocBase1' (9202)
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: https://localhost:9202/IndexAgent/
Transfer-Encoding: chunked
Date: Sat, 22 Jul 2017 11:36:57 GMT


  ** Accessing IndexAgent URL of 'DctmServer_Indexagent_DocBase2' (9222)
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: https://localhost:9222/IndexAgent/
Transfer-Encoding: chunked
Date: Sat, 22 Jul 2017 11:36:57 GMT


  ** Accessing IndexAgent URL of 'DctmServer_Indexagent_DocBase3' (9242)
HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: https://localhost:9242/IndexAgent/
Transfer-Encoding: chunked
Date: Sat, 22 Jul 2017 11:36:58 GMT
[dmadmin@content_server_01 ~]$

 

For the Dsearch, the proper answer is a HTTP 259 return code while for the IndexAgent, I didn’t put an ending “/” in the URL so that we don’t have the full page of the IA loaded but only some header. Therefore HTTP 302 Moved Temporarily is the proper return code there.

 

Please note that for the “sed” commands above, I deliberately used “<[sk][se][ly]” even if for all JBoss 7.1.1 instances, the SSL configuration will always start with “<ssl “. The reason for that is to make the steps compatible with WidlFly 9.0.1 too (xPlore 1.6). There are a few differences between JBoss 7.1.1 and WildFly 9.0.1 and one of them is that the JKS password is now on a line starting with “<keystore ” so that’s why :).

 

 

Cet article Documentum – Change password – 6 – CS/FT – JKS est apparu en premier sur Blog dbi services.


Documentum – Change password – 7 – DB – Schema Owner

$
0
0

In this serie, I completed the passwords I wanted to talk about on the Content Server. Therefore in this blog, I will talk about the only Database Account that is relevant for Documentum: the Database Schema Owner. Since there are a few steps to be done on the Content Server, I’m just doing everything from there… In this blog, I will assume there is one Global Registry (GR_DOCBASE) and one normal Repository (DocBase1). Each docbase has a different Database Schema Owner of course but both Schemas are on the same Database and therefore the same SID will be used.

 

In High Availability setups, you will have to execute the steps below for all Content Servers. Of course, when it comes to changing the password inside the DB, this needs to be done only once since the Database Schema Owner is shared between the different Content Servers of the HA setup.

 

In this blog, I’m using a CS 7.2. Please note that in CS 7.2, there is a property inside the dfc.properties of the Content Server ($DOCUMENTUM_SHARED/config/dfc.properties) that defines the crypto repository (dfc.crypto.repository). The repository that is used for this property is the one that Documentum will use for encryption/decryption of passwords and therefore I will use this one below to encrypt the password. By default, the Repository used for this property is the last one created… I tend to use the Global Registry instead, but it’s really up to you.

 

As said before, I’m considering two different repositories and therefore two different accounts and two different passwords. So, let’s start with encrypting these two passwords:

[dmadmin@content_server_01 ~]$ read -s -p "Please enter the NEW GR_DOCBASE Schema Owner's password: " new_gr_pw; echo
Please enter the NEW GR_DOCBASE Schema Owner's password:
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ read -s -p "Please enter the NEW DocBase1 Schema Owner's password: " new_doc1_pw; echo
Please enter the NEW DocBase1 Schema Owner's password:
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ iapi `cat $DOCUMENTUM_SHARED/config/dfc.properties | grep crypto | tail -1 | sed 's/.*=//'` -Udmadmin -Pxxx << EOF
> encrypttext,c,${new_gr_pw}
> encrypttext,c,${new_doc1_pw}
> EOF


    EMC Documentum iapi - Interactive API interface
    (c) Copyright EMC Corp., 1992 - 2015
    All rights reserved.
    Client Library Release 7.2.0150.0154


Connecting to Server using docbase GR_DOCBASE
[DM_SESSION_I_SESSION_START]info:  "Session 010f12345605ae7b started for user dmadmin."


Connected to Documentum Server running Release 7.2.0160.0297  Linux64.Oracle
Session id is s0
API> ...
DM_ENCR_TEXT_V2=AAAAEH7UNwFub2ubf92h+21/rc8HEc3rd1C82hc52c8bz2cFl1cQ721zex2nxWDEegwqgdotwncZVVqgZlDLmfflWK6+f8AGf0dSRzi5rr3h3::GR_DOCBASE
API> ...
DM_ENCR_TEXT_V2=AAAAEGBQ6Zy7FxQ10idQdFj+Gn20nFlif02ieMx+AGBHLz+vQfmGu2GAiv8KeIN2PhPOf1oiF9u2fP98zEFhhuBAmxY+d5AoBCGNf61ZRavpa::GR_DOCBASE
API> Bye
[dmadmin@content_server_01 ~]$

 

If you have more repositories, you will have to encrypt those too, if you want to change them of course. Once the new password has been encrypted, we can change it on the Database. To avoid any issues and error messages, let’s first stop Documentum (the docbases at the very least) and then printing the Database Connection information:

[dmadmin@content_server_01 ~]$ service documentum stop
  ** JMS stopped
  ** DocBase1 stopped
  ** GR_DOCBASE stopped
  ** Docbroker stopped
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ cat $ORACLE_HOME/network/admin/tnsnames.ora
<sid> =
    (DESCRIPTION =
        (ADDRESS_LIST =
            (ADDRESS = (PROTOCOL = TCP)(HOST = <database_hostname>)(PORT = <database_port>))
        )
        (CONNECT_DATA =
            (SERVICE_NAME = <service_name>)
        )
    )
[dmadmin@content_server_01 ~]$

 

Once you know what the SID is, you can now login to the database to change the password so I will do that for both repositories. This could also be scripted to retrieve the list of docbases, create new passwords for them, encrypt them all automatically and then connect to each database using different SQL scripts to change the passwords, however I will use here manual steps:

[dmadmin@content_server_01 ~]$ sqlplus GR_DOCBASE@<sid>

SQL*Plus: Release 12.1.0.2.0 Production on Sat Jul 22 15:05:08 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password:
    -->> Enter here the OLD GR_DOCBASE Schema Owner's password
Last Successful login time: Sat Jul 22 2017 15:04:18 +00:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics, Real Application Testing
and Unified Auditing options

SQL> PASSWORD
Changing password for GR_DOCBASE
Old password:
    -->> Enter here the OLD GR_DOCBASE Schema Owner's password
New password:
    -->> Enter here the NEW GR_DOCBASE Schema Owner's password
Retype new password:
    -->> Re-enter here the NEW GR_DOCBASE Schema Owner's password
Password changed

SQL> quit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics, Real Application Testing
and Unified Auditing options
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ sqlplus DocBase1@<sid>

SQL*Plus: Release 12.1.0.2.0 Production on Sat Jul 22 15:08:20 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

Enter password:
    -->> Enter here the OLD DocBase1 Schema Owner's password
Last Successful login time: Sat Jul 22 2017 15:07:10 +00:00

Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics, Real Application Testing
and Unified Auditing options

SQL> PASSWORD
Changing password for DocBase1
Old password:
    -->> Enter here the OLD DocBase1 Schema Owner's password
New password:
    -->> Enter here the NEW DocBase1 Schema Owner's password
Retype new password:
    -->> Re-enter here the NEW DocBase1 Schema Owner's password
Password changed

SQL> quit
Disconnected from Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics, Real Application Testing
and Unified Auditing options
[dmadmin@content_server_01 ~]$

 

At this point, the passwords have been changed in the database and we encrypted them properly. The next step is therefore to update the password files for each repository with the encrypted password so that the repositories can start again:

[dmadmin@content_server_01 ~]$ cd $DOCUMENTUM/dba/config
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ for i in `ls -d *`; do echo "  ** dbpasswd.txt for ${i} **"; cat ./${i}/dbpasswd.txt; echo; done
  ** dbpasswd.txt for GR_DOCBASE **
DM_ENCR_TEXT_V2=AAAAEH7UNwFgncubfd1C82hc5l1cwqgdotwQ7212c8bz2cFZVVqgZub2zex8bz2cFWK92h+21EelDLmffl2/rc82c8bz2cFf0dSRazi5rr3h3::GR_DOCBASE

  ** dbpasswd.txt for DocBase1 **
DM_ENCR_TEXT_V2=AAAAQ10idQdFj+Gn2EGBPZy7e0niF9uQfAGBHLz+vv8KQ62fP98zE+02iFhhuBAmxY+FFxeMxIN2Phl1od5AoBCGNf61ZRifmGu2GAiOfavpa::GR_DOCBASE

[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ for i in `ls -d *`; do cp ./${i}/dbpasswd.txt ./${i}/dbpasswd.txt_bck_$(date +"%Y%m%d-%H%M%S"); done
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ echo "DM_ENCR_TEXT_V2=AAAAEH7UNwFub2ubf92h+21/rc8HEc3rd1C82hc52c8bz2cFl1cQ721zex2nxWDEegwqgdotwncZVVqgZlDLmfflWK6+f8AGf0dSRzi5rr3h3::GR_DOCBASE" > ./GR_DOCBASE/dbpasswd.txt
[dmadmin@content_server_01 ~]$ echo "DM_ENCR_TEXT_V2=AAAAEGBQ6Zy7FxQ10idQdFj+Gn20nFlif02ieMx+AGBHLz+vQfmGu2GAiv8KeIN2PhPOf1oiF9u2fP98zEFhhuBAmxY+d5AoBCGNf61ZRavpa::GR_DOCBASE" > ./DocBase1/dbpasswd.txt
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ for i in `ls -d *`; do echo "  ** dbpasswd.txt for ${i} **"; cat ./${i}/dbpasswd.txt; echo; done
  ** dbpasswd.txt for GR_DOCBASE **
DM_ENCR_TEXT_V2=AAAAEH7UNwFub2ubf92h+21/rc8HEc3rd1C82hc52c8bz2cFl1cQ721zex2nxWDEegwqgdotwncZVVqgZlDLmfflWK6+f8AGf0dSRzi5rr3h3::GR_DOCBASE

  ** dbpasswd.txt for DocBase1 **
DM_ENCR_TEXT_V2=AAAAEGBQ6Zy7FxQ10idQdFj+Gn20nFlif02ieMx+AGBHLz+vQfmGu2GAiv8KeIN2PhPOf1oiF9u2fP98zEFhhuBAmxY+d5AoBCGNf61ZRavpa::GR_DOCBASE

[dmadmin@content_server_01 ~]$

 

Once the dbpasswd.txt files have been updated with the new encrypted password that has been generated at the beginning of this blog, then we can restart Documentum and verify that the docbases are up&running. If they are, then the password has been changed properly!

[dmadmin@content_server_01 ~]$ service documentum start
  ** Docbroker started
  ** GR_DOCBASE started
  ** DocBase1 started
  ** JMS started
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ ps -ef | grep "documentum.*docbase_name"
...
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ grep -C3 "DM_DOCBROKER_I_PROJECTING" $DOCUMENTUM/dba/log/GR_DOCBASE.log
2017-07-22T15:28:40.657360      9690[9690]      0000000000000000        [DM_SERVER_I_START]info:  "Sending Initial Docbroker check-point "

2017-07-22T15:28:40.671878      9690[9690]      0000000000000000        [DM_MQ_I_DAEMON_START]info:  "Message queue daemon (pid : 9870, session 010f123456000456) is started sucessfully."
2017-07-22T15:28:40.913699      9869[9869]      010f123456000003        [DM_DOCBROKER_I_PROJECTING]info:  "Sending information to Docbroker located on host (content_server_01) with port (1490).  Information: (Config(GR_DOCBASE), Proximity(1), Status(Open), Dormancy Status(Active))."
Tue Jul 22 15:29:38 2017 [INFORMATION] [AGENTEXEC 10309] Detected during program initialization: Version: 7.2.0160.0297  Linux64
Tue Jul 22 15:29:44 2017 [INFORMATION] [AGENTEXEC 10309] Detected during program initialization: Agent Exec connected to server GR_DOCBASE:  [DM_SESSION_I_SESSION_START]info:  "Session 010f123456056d00 started for user dmadmin."

[dmadmin@content_server_01 ~]$

 

When the docbase has been registered to the Docbroker, you are sure that it was able to contact and log in to the database so that the new password is now used properly. To be sure that everything in Documentum is working properly however, I would still check the complete log file…

 

 

Cet article Documentum – Change password – 7 – DB – Schema Owner est apparu en premier sur Blog dbi services.

Documentum – Change password – 8 – FT – Dsearch & xDB

$
0
0

Here we are, already, at the end of my series of blogs about the “Change Password”. This blog will, as already mentioned in a previous one, talk about the Dsearch and xDB passwords. I could have created a lot more blogs in this series but I already presented the most important and most interesting ones so this blog will be the last one – at least for now ;).

 

Please note that below, I will set the same password for the Dsearch admin account and for the xDB. The reason for that is pretty simple: this is what Documentum is doing by default when you install a PrimaryDsearch. Indeed, when you install a Dsearch, the installer will ask you to enter the Dsearch admin account which is the JBoss instance admin account (this blog explained how to change a JBoss Admin password) and it will use this password for the xDB too.

If you want to use a different password, then you can potentially define three passwords here: xDB Admin password, xDB Superuser password and Dsearch JBoss instance password.

 

The xDB (find more info here about what it is) provides a command line interface to manage it (repair, create, list, aso…) which is the “XHCommand” but you aren’t able to change the different passwords through this CLI ;(. Therefore, before even starting with this blog, you will have to start a X Server or something similar, to be able to open the xDB Admin GUI (“XHAdmin”). For this blog, I installed a new VM and I also installed the complete graphical interface on it (my first time in a very long time) in order to have some screenshots that aren’t too ugly…

 

So first of all, let’s login to the Full Text Server and open the xDB Admin GUI:

[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/dsearch/xhive/admin/
[xplore@full_text_server_01 ~]$ ./XHAdmin

 

Just a small funny note, when you will close the XHAdmin tool, you will see that EMC thanks you for using this tool: “Thank you for using EMC Documentum xDB”. I guess this is your reward for having to open a GUI to change a password, in 2017 ;).

 

At this point, the xDB Admin Client will be opened but not connected. So the first thing to do is to connect to the xDB with the CURRENT Dsearch Admin credentials:

  • Click on the “connect” button
  • Set the “Database name” to: xhivedb
  • Set the “Username” to: Administrator
  • Set the “Password” to: ###CURRENT_DSEARCH_ADMIN_PWD###
  • Click on the “OK” button

Dsearch-xDB_Change_Password_1

 

Then you will be connected to the xDB. Therefore, it is now time to change the Superuser password:

  • Click on the “Federation > Change superuser password” menu
  • Set the “New superuser password” to: ###NEW_DSEARCH_ADMIN_PWD###
  • Set the “Retype password” to: ###NEW_DSEARCH_ADMIN_PWD###
  • Click on the “OK” button
  • A pop-up will be opened with a title “Enter superuser password”. Enter the ###CURRENT_DSEARCH_ADMIN_PWD### in it and click on OK to validate the change.

Dsearch-xDB_Change_Password_2

 

After that, time to change the Admin password itself. Here, you have the use the new Superuser password that has been defined above and then define the new Admin password:

  • Click on the “Database > Reset admin password” menu
  • Set the “Database name” to: xhivedb
  • Set the “Superuser password” to: ###NEW_DSEARCH_ADMIN_PWD###
  • Set the “Administrator password” to: ###NEW_DSEARCH_ADMIN_PWD###
  • Set the “Retype password” to: ###NEW_DSEARCH_ADMIN_PWD###
  • Click on the “OK” button

Dsearch-xDB_Change_Password_3

 

At this point, the xDB Superuser and Admin passwords have been defined so you can close the xDB Admin Client (Database > Exit) and we can go back to the command line. Ok so now let’s stop the xPlore components in order to reflect these changes on the configuration files:

[xplore@full_text_server_01 ~]$ read -s -p "Please enter the NEW Dsearch Admin password: " newpw; echo
Please enter the NEW Dsearch Admin password:
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server
[xplore@full_text_server_01 ~]$ for i in `ls stop*.sh`; do ./${i}; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server/DctmServer_PrimaryDsearch/deployments/dsearch.war/WEB-INF/classes/
[xplore@full_text_server_01 ~]$ cp indexserver-bootstrap.properties indexserver-bootstrap.properties_bck_$(date +"%Y%m%d-%H%M%S")
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ grep "password=" indexserver-bootstrap.properties
superuser-password=AAAAEF1hfFDU0zff6A6Mmd1f6Le8VvxPmLxF11ZdzjVo5KU/
adminuser-password=AAAAEF1hfFDU0zff6A6Mmd1f6Le8VvxPmLxF11ZdzjVo5KU/
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sed -i "s,password=.*,password=${newpw}," indexserver-bootstrap.properties
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ grep "password=" indexserver-bootstrap.properties
superuser-password=New_Dsearch_Admin_Pwd
adminuser-password=New_Dsearch_Admin_Pwd
[xplore@full_text_server_01 ~]$

 

As you can see above, I’m defining the environment variable with the NEW Dsearch Admin Password and then I’m replacing the superuser and adminuser encrypted OLD password inside the file indexserver-bootstrap.properties with the non-encrypted NEW password. It was the same for both before and it is still the same for both after. Don’t worry about putting the non-encrypted NEW password in this properties file, it will be encrypted automatically at the next start of the PrimaryDsearch. So now, let’s start the Dsearch only to verify if the passwords have been encrypted successfully and then we can update the Dsearch JBoss Admin password:

[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server
[xplore@full_text_server_01 ~]$ nohup ./startPrimaryDsearch.sh >> nohup-PrimaryDsearch.out 2>&1 &
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sleep 60
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ grep "password=" ./DctmServer_PrimaryDsearch/deployments/dsearch.war/WEB-INF/classes/indexserver-bootstrap.properties
superuser-password=AAAAFAq2fFwiHf21P98hRch982+1hEDGe824E21eL21e9c57f6A
adminuser-password=AAAAFAq2fFwiHf21P98hRch982+1hEDGe824E21eL21e9c57f6A
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server/DctmServer_PrimaryDsearch/configuration
[xplore@full_text_server_01 ~]$ cp dctm-users.properties dctm-users.properties_bck_$(date +"%Y%m%d-%H%M%S")
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ encrypted_newpw=`grep "adminuser-password=" ../deployments/dsearch.war/WEB-INF/classes/indexserver-bootstrap.properties | sed 's,adminuser-password=,,'`
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ echo "# users.properties file to use with UsersRolesLoginModule" > dctm-users.properties
[xplore@full_text_server_01 ~]$ echo "admin=${encrypted_newpw}" >> dctm-users.properties
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ cat dctm-users.properties
# users.properties file to use with UsersRolesLoginModule
admin=AAAAFAq2fFwiHf21P98hRch982+1hEDGe824E21eL21e9c57f6A
[xplore@full_text_server_01 ~]$

 

If you are referring to the JBoss Admin password blog I already published and that I linked above, you could think that there is nothing more to be done but actually there is one more file that needs to be updated when it comes to the Dsearch Admin password and this file is the xplore.properties:

[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/dsearch/admin/
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ grep -B2 "password=" xplore.properties
# Specify admin password for xPlore primary instance
# It is highly suggested to input the encrypted password, you can get it from indexserver-bootstrap.properties
password=AAAAEF1hfFDU0zff6A6Mmd1f6Le8VvxPmLxF11ZdzjVo5KU/
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sed -i "s,password=.*,password=${encrypted_newpw}," xplore.properties
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ grep -B2 "password=" xplore.properties
# Specify admin password for xPlore primary instance
# It is highly suggested to input the encrypted password, you can get it from indexserver-bootstrap.properties
password=AAAAFAq2fFwiHf21P98hRch982+1hEDGe824E21eL21e9c57f6A
[xplore@full_text_server_01 ~]$

 

To complete the changes, we can now restart all xPlore components and verify that the PrimaryDsearch has been started properly:

[xplore@full_text_server_01 ~]$ cd $XPLORE_HOME/jboss7.1.1/server
[xplore@full_text_server_01 ~]$ ./stopPrimaryDsearch.sh
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sleep 30
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ nohup ./startPrimaryDsearch.sh >> nohup-PrimaryDsearch.out 2>&1 &
[xplore@full_text_server_01 ~]$ for i in `ls startIndexag*.sh`; do ia=`echo $i|sed 's,start\(.*\).sh,\1,'`; nohup ./$i >> nohup-$ia.out 2>&1 &; done
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ sleep 30
[xplore@full_text_server_01 ~]$
[xplore@full_text_server_01 ~]$ curl -g --user admin -D - http://localhost:9305/management --header "Content-Type: application/json" -d '{"operation":"read-attribute","name":"server-state","json.pretty":1}'
Enter host password for user 'admin':
HTTP/1.1 200 OK
Transfer-encoding: chunked
Content-type: application/json
Date: Sun, 23 Jul 2017 08:14:56 GMT

{
    "outcome" : "success",
    "result" : "running"
}
[xplore@full_text_server_01 ~]$

 

To be sure, you can also open the Dsearch Admin UI (E.g.: https://hostname:9302/dsearchadmin) and then log in with the NEW Dsearch Admin password. If the login is working, you should be good to go! :)

 

 

Cet article Documentum – Change password – 8 – FT – Dsearch & xDB est apparu en premier sur Blog dbi services.

Documentum – Using DA with Self-Signed SSL Certificate

$
0
0

A few years ago, I was working on a Documentum project and one of the tasks was to setup all components in SSL. I already published a lot of blogs on this subject but there is one I wanted to do but never really took the time to publish it. In this blog, I will therefore talk about Documentum Administrator in SSL using a Self-Sign SSL Certificate. Recently, a colleague of mine had the same issue at another customer so I provided him the full procedure that I will describe below. However, since the process below requires the signature of a jar file and since this isn’t available for all companies, you might want to check out my colleague’s blog too.

A lot of companies are working with their own SSL Trust Chain, meaning that they provide/create their own SSL Certificate (Self-Signed) including their Root and Intermediate SSL Certificate for the trust. End-users will not really notice the difference but they are actually using Self-Sign SSL Certificate. This has some repercussions when working with Documentum since you need to import the SSL Trust Chain on the various Application Servers (JMS, WebLogic, Dsearch, aso…). This is pretty simple but there is one thing that is a little bit trickier and this is related to Documentum Administrator.

Below, I will use a DA 7.2 P16 (that is therefore pretty recent) but the same applies to all patches of DA 7.2 and 7.3. For information, we didn’t face this issue with DA 7.1 so something most probably changed between DA 7.1 and 7.2. If you are seeing the same thing with a DA 7.1, feel free to put a comment below, I would love to know! When you are accessing DA for the first time, you will actually download a JRE which will be put under C:\Users\<user_name>\Documentum\ucf\<machine_name>, by default. This JRE is used for various stuff including the transfer of files (UCF), display of DA preferences, aso… DA isn’t taking the JRE from the website of Oracle, it is, in fact, taking it from the da.war file. The DA war file always contains two or three different JREs versions. Now if you want to use DA in HTTPS, these JREs will also need to contain your custom SSL Trust Chain. So how can you do that?

Well a simple answer would be: just like for the JMS or WebLogic, just import the custom SSL Trust Chain in the “cacerts” of these JREs. That will actually not work for a very vicious reason: EMC is now signing all the files provided and that also include the JREs inside da.war (well actually they are signing the checksums of the JREs, not the JREs themselves). Because of this signature, if you edit the cacerts file of the JREs, DA will say something like that: “Invalid checksum for the file ‘win-jre1.8.0_91.zip'”. This checksum ensures that the JREs and all the files you are using on your local workstation that have been downloaded from the da.war are the one provided by EMC. This is good from a security point of view since it prevents intruders to exchanges the files during transfer or directly on your workstation but that also prevents you from updating the JREs with your custom SSL Trust Chain.

 

So what I will do below to update the Java cacerts AND still keep a valid signature is:

  1. Extract the JREs and ucfinit.jar file from da.war
  2. Update the cacerts of each JREs with a custom SSL Trust Chain (Root + Intermediate)
  3. Repackage the JREs
  4. Calculate the checksum of the JREs using the ComputeChecksum java class
  5. Extract the old checksum files from ucfinit.jar
  6. Replace the old checksum files for the JREs with the new one generated on step 4
  7. Remove .RSA and .SF files from the META-INF folder and clean the MANIFEST to remove Documentum’s digital signature
  8. Recreate the file ucfinit.jar with the clean manifest and all other files
  9. Ask the company’s dedicated team to sign the new jar file
  10. Repackage da.war with the updated JREs and the updated/signed ucfinit.jar

 

I will use below generic commands that do not specify any version of the JREs or DA because there will be two or three different JREs and the versions will change depending on your DA Patch level, so better stay generic. I will also use my custom SSL Trust Chain which I put under /tmp.

In this first part, I will create a working folder to avoid messing with the deployed applications. Then I will extract the needed files and finally remove all files and folders that I don’t need. That’s the step 1:

[weblogic@weblogic_server_01 ~]$ mkdir /tmp/workspace; cd /tmp/workspace
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ cp $WLS_APPLICATIONS/da.war .
[weblogic@weblogic_server_01 workspace]$ ls
da.war
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ jar -xvf da.war wdk/system/ucfinit.jar wdk/contentXfer/
  created: wdk/contentXfer/
 inflated: wdk/contentXfer/All-MB.jar
 ...
 inflated: wdk/contentXfer/Web/Emc.Documentum.Ucf.Client.Impl.application
 inflated: wdk/contentXfer/win-jre1.7.0_71.zip
 inflated: wdk/contentXfer/win-jre1.7.0_72.zip
 inflated: wdk/contentXfer/win-jre1.8.0_91.zip
 inflated: wdk/system/ucfinit.jar
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ cd ./wdk/contentXfer/
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ ls
All-MB.jar                                    jacob.dll                 libUCFSolarisGNOME.so   ucf-client-installer.zip  win-jre1.8.0_91.zip
Application Files                             jacob.jar                 libUCFSolarisJNI.so     ucf.installer.config.xml
Emc.Documentum.Ucf.Client.Impl.application    libMacOSXForkerIO.jnilib  licenses                UCFWin32JNI.dll
ES1_MRE.msi                                   libUCFLinuxGNOME.so       MacOSXForker.jar        Web
ExJNIAPI.dll                                  libUCFLinuxJNI.so         mac_utilities.jar       win-jre1.7.0_71.zip
ExJNIAPIGateway.jar                           libUCFLinuxKDE.so         ucf-ca-office-auto.jar  win-jre1.7.0_72.zip
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ for i in `ls | grep -v 'win-jre'`; do rm -rf "./${i}"; done
[weblogic@weblogic_server_01 contentXfer]$ rm -rf ./*/
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ ls
win-jre1.7.0_71.zip  win-jre1.7.0_72.zip  win-jre1.8.0_91.zip
[weblogic@weblogic_server_01 contentXfer]$

 

At this point, only the JREs are present in the current folder (wdk/contentXfer) and I also have another file in another folder (wdk/system/ucfinit.jar). Once that is done, I’m creating a list of the JREs available that I will use for the whole blog and I’m also performing the steps 2 and 3, to extract the cacerts from the JREs, update them and finally repackage them (this is where I use the custom SSL Trust Chain):

[weblogic@weblogic_server_01 contentXfer]$ ls win-jre* | sed -e 's/.*win-//' -e 's/.zip//' > /tmp/list_jre.txt
[weblogic@weblogic_server_01 contentXfer]$ cat /tmp/list_jre.txt
jre1.7.0_71
jre1.7.0_72
jre1.8.0_91
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ while read line; do unzip -x win-${line}.zip ${line}/lib/security/cacerts; done < /tmp/list_jre.txt
Archive:  win-jre1.7.0_71.zip
  inflating: jre1.7.0_71/lib/security/cacerts
Archive:  win-jre1.7.0_72.zip
  inflating: jre1.7.0_72/lib/security/cacerts
Archive:  win-jre1.8.0_91.zip
  inflating: jre1.8.0_91/lib/security/cacerts
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ while read line; do keytool -import -noprompt -trustcacerts -alias custom_root_ca -keystore ${line}/lib/security/cacerts -file /tmp/Company_Root_CA.cer -storepass changeit; done < /tmp/list_jre.txt
Certificate was added to keystore
Certificate was added to keystore
Certificate was added to keystore
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ while read line; do keytool -import -noprompt -trustcacerts -alias custom_int_ca -keystore ${line}/lib/security/cacerts -file /tmp/Company_Intermediate_CA.cer -storepass changeit; done < /tmp/list_jre.txt
Certificate was added to keystore
Certificate was added to keystore
Certificate was added to keystore
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ while read line; do zip -u win-${line}.zip ${line}/lib/security/cacerts; done < /tmp/list_jre.txt
updating: jre1.7.0_71/lib/security/cacerts (deflated 35%)
updating: jre1.7.0_72/lib/security/cacerts (deflated 35%)
updating: jre1.8.0_91/lib/security/cacerts (deflated 33%)
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ while read line; do rm -rf ./${line}; done < /tmp/list_jre.txt
[weblogic@weblogic_server_01 contentXfer]$

 

At this point, the JREs have been updated with a new “cacerts” and therefore its checksum changed. It doesn’t match the signed checksum anymore so if you try to deploy DA at this point, you will get the error message I put above. So, let’s perform the steps 4, 5 and 6. For that purpose, I will use the file /tmp/ComputeChecksum.class that was provided by EMC. This class is needed in order to recalculate the new checksum of the JREs:

[weblogic@weblogic_server_01 contentXfer]$ pwd
/tmp/workspace/wdk/contentXfer
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ cp /tmp/ComputeChecksum.class .
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ ls
ComputeChecksum.class  win-jre1.7.0_71.zip  win-jre1.7.0_72.zip  win-jre1.8.0_91.zip
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ java ComputeChecksum .
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ ls
ComputeChecksum.class           win-jre1.7.0_71.zip           win-jre1.7.0_72.zip           win-jre1.8.0_91.zip
ComputeChecksum.class.checksum  win-jre1.7.0_71.zip.checksum  win-jre1.7.0_72.zip.checksum  win-jre1.8.0_91.zip.checksum
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ rm ComputeChecksum.class*
[weblogic@weblogic_server_01 contentXfer]$
[weblogic@weblogic_server_01 contentXfer]$ cd /tmp/workspace/wdk/system/
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ pwd
/tmp/workspace/wdk/system
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ ls
ucfinit.jar
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ jar -xvf ucfinit.jar
 inflated: META-INF/MANIFEST.MF
 inflated: META-INF/COMPANY.SF
 inflated: META-INF/COMPANY.RSA
  created: META-INF/
 inflated: All-MB.jar.checksum
  created: com/
  created: com/documentum/
  ...
 inflated: UCFWin32JNI.dll.checksum
 inflated: win-jre1.7.0_71.zip.checksum
 inflated: win-jre1.7.0_72.zip.checksum
 inflated: win-jre1.8.0_91.zip.checksum
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ mv /tmp/workspace/wdk/contentXfer/win-jre*.checksum .
[weblogic@weblogic_server_01 system]$

 

With this last command, the new checksum have replaced the old ones. The next step is now to remove the old signatures (.RSA and .SF files + content of the manifest) and the repack the ucfinit.jar file (step 7 and 8):

[weblogic@weblogic_server_01 system]$ rm ucfinit.jar META-INF/*.SF META-INF/*.RSA
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ sed -i -e '/^Name:/d' -e '/^SHA/d' -e '/^ /d' -e '/^[[:space:]]*$/d' META-INF/MANIFEST.MF
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.4
Title: Documentum Client File Selector Applet
Bundle-Version: 7.2.0160.0058
Application-Name: Documentum
Built-By: dmadmin
Build-Version: 7.2.0160.0058
Permissions: all-permissions
Created-By: 1.6.0_30-b12 (Sun Microsystems Inc.)
Copyright: Documentum Inc. 2001, 2004
Caller-Allowable-Codebase: *
Build-Date: August 16 2016 06:35 AM
Codebase: *
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ vi META-INF/MANIFEST.MF
    => Add a new empty line at the end of this file with vi, vim, nano or whatever... The file must always end with an empty line.
    => Do NOT use the command "echo '' >> META-INF/MANIFEST.MF" because it will change the fileformat of the file which complicate the signature (usually the FF is DOS...)
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ jar -cmvf META-INF/MANIFEST.MF ucfinit.jar *
added manifest
adding: All-MB.jar.checksum(in = 28) (out= 30)(deflated -7%)
adding: com/(in = 0) (out= 0)(stored 0%)
adding: com/documentum/(in = 0) (out= 0)(stored 0%)
adding: com/documentum/ucf/(in = 0) (out= 0)(stored 0%)
...
adding: UCFWin32JNI.dll.checksum(in = 28) (out= 30)(deflated -7%)
adding: win-jre1.7.0_71.zip.checksum(in = 28) (out= 30)(deflated -7%)
adding: win-jre1.7.0_72.zip.checksum(in = 28) (out= 30)(deflated -7%)
adding: win-jre1.8.0_91.zip.checksum(in = 28) (out= 30)(deflated -7%)
[weblogic@weblogic_server_01 system]$

 

At this point, the file ucfinit.jar has been recreated with an “empty” manifest, without signature but with all the new checksum files. Therefore, it is now time to send this file (ucfinit.jar) to your code signing team (step 9). This is out of scope for this blog but basically what will be done by your signature team is the creation of the .RSA and .SF files inside the folder META-INF as well as the repopulation of the manifest. The .SF and the manifest will contain more or less the same thing: the different files of the ucfinit.jar files will have their entries in these files with a pair filename/signature. At this point, we therefore have re-signed the checksum of the JREs.

 

The last step is now to repack the da.war with the new ucfinit.jar file which has been signed. I put the new signed file under /tmp:

[weblogic@weblogic_server_01 system]$ pwd
/tmp/workspace/wdk/system
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ rm -rf *
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ ll
total 0
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ cp /tmp/ucfinit.jar .
[weblogic@weblogic_server_01 system]$
[weblogic@weblogic_server_01 system]$ cd /tmp/workspace/
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ ls wdk/*
wdk/contentXfer:
win-jre1.7.0_71.zip  win-jre1.7.0_72.zip  win-jre1.8.0_91.zip

wdk/system:
ucfinit.jar
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ jar -uvf da.war wdk
adding: wdk/(in = 0) (out= 0)(stored 0%)
adding: wdk/contentXfer/(in = 0) (out= 0)(stored 0%)
adding: wdk/contentXfer/win-jre1.7.0_71.zip(in = 41373620) (out= 41205241)(deflated 0%)
adding: wdk/contentXfer/win-jre1.7.0_72.zip(in = 41318962) (out= 41137924)(deflated 0%)
adding: wdk/contentXfer/win-jre1.8.0_91.zip(in = 62424686) (out= 62229724)(deflated 0%)
adding: wdk/system/(in = 0) (out= 0)(stored 0%)
adding: wdk/system/ucfinit.jar(in = 317133) (out= 273564)(deflated 13%)
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ mv $WLS_APPLICATIONS/da.war $WLS_APPLICATIONS/da.war_bck_beforeSignature
[weblogic@weblogic_server_01 workspace]$
[weblogic@weblogic_server_01 workspace]$ mv da.war $WLS_APPLICATIONS/
[weblogic@weblogic_server_01 workspace]$

 

Once this has been done, simply redeploy the Documentum Administrator and the next time you will access it in HTTPS, you will be able to transfer files, view the DA preferences, aso… The JREs are now trusted automatically because the checksum of the JRE is now signed properly.

 

 

Cet article Documentum – Using DA with Self-Signed SSL Certificate est apparu en premier sur Blog dbi services.

Documentum – Unable to install xCP 2.3 on a CS 7.3

$
0
0

Beginning of this year, we were doing our first silent installations of the new Documentum stack. I already created a few blogs to talk about some issues with CS 7.3 and xPlore 1.6. This time, I will talk about xCP 2.3 and in particular the installation on a CS 7.3. The Patch of xCP as well as the patch for the CS 7.3 doesn’t matter since all versions are affected. Please just note that the first supported patch on a CS 7.3 is xCP 2.3 P03 so you shouldn’t be installing a previous patch on 7.3.

So, when installing an xCP 2.3 on a Content Server 7.3, you will get a pop-up in the installer with the following error message: “Installation of DARs failed”. You will only have an “OK” button on this pop-up which will close the installer. Ok so there is an issue with the installation of the DARs but what’s the issue exactly?

 

On the installation log file, we can see the following:

[dmadmin@content_server_01 ProcessEngine]$ cat logs/install.log
13:44:45,356  INFO [Thread-8] com.documentum.install.pe.installanywhere.actions.PEInitializeSharedLibrary - Done InitializeSharedLibrary ...
13:44:45,395  INFO [Thread-10] com.documentum.install.appserver.jboss.JbossApplicationServer - setApplicationServer sharedDfcLibDir is:$DOCUMENTUM_SHARED/dfc
13:44:45,396  INFO [Thread-10] com.documentum.install.appserver.jboss.JbossApplicationServer - getFileFromResource for templates/appserver.properties
13:44:45,532  WARN [Thread-10] com.documentum.install.pe.installanywhere.actions.DiWAPeInitialize - init-param tags found in Method Server webapp:

<init-param>
      <param-name>docbase_install_owner_name</param-name>
      <param-value>dmadmin</param-value>
</init-param>
<init-param>
      <param-name>docbase-GR_DOCBASE</param-name>
      <param-value>GR_DOCBASE</param-value>
</init-param>
<init-param>
      <param-name>docbase-DocBase1</param-name>
      <param-value>DocBase1</param-value>
</init-param>
<init-param>
      <param-name>docbase-DocBase2</param-name>
      <param-value>DocBase2</param-value>
</init-param>
13:44:58,771  INFO [AWT-EventQueue-0] com.documentum.install.pe.ui.panels.DiWPPELicenseAgreementPanel - UserSelection: "I accept the terms of the license agreement."
13:46:13,398  INFO [AWT-EventQueue-0] com.documentum.install.appserver.jboss.JbossApplicationServer - The batch file: $DOCUMENTUM_SHARED/temp/installer/wildfly/dctm_tmpcmd0.sh exist? false
13:46:13,399  INFO [AWT-EventQueue-0] com.documentum.install.appserver.jboss.JbossApplicationServer - The user home is : /home/dmadmin
13:46:13,405  INFO [AWT-EventQueue-0] com.documentum.install.appserver.jboss.JbossApplicationServer - Executing temporary batch file: $DOCUMENTUM_SHARED/temp/installer/wildfly/dctm_tmpcmd0.sh for running: $DOCUMENTUM_SHARED/java64/1.8.0_77/bin/java -cp $DOCUMENTUM_SHARED/wildfly9.0.1/modules/system/layers/base/emc/documentum/security/main/dfc.jar:$DOCUMENTUM_SHARED/wildfly9.0.1/modules/system/layers/base/emc/documentum/security/main/aspectjrt.jar:$DOCUMENTUM_SHARED/wildfly9.0.1/modules/system/layers/base/emc/documentum/security/main/DctmUtils.jar com.documentum.install.appserver.utils.DctmAppServerAuthenticationString $DOCUMENTUM_SHARED/wildfly9.0.1/server/DctmServer_MethodServer jboss
13:46:42,320  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeInstallActions - starting DctmActions
13:46:42,724  INFO [installer] com.documentum.install.appserver.jboss.JbossApplicationServer - user name = admin
13:46:42,724  INFO [installer] com.documentum.install.appserver.jboss.JbossApplicationServer - Server DctmServer_MethodServer already exists!
13:46:42,725  INFO [installer] com.documentum.install.appserver.jboss.JbossApplicationServer - Deploying to Group MethodServer... bpm (bpm.ear): does not exist!
13:46:42,725  INFO [installer] com.documentum.install.appserver.jboss.JbossApplicationServer - resolving $DOCUMENTUM_SHARED/wildfly9.0.1/server/DctmServer_MethodServer/deployments/bpm.ear/APP-INF/classes/dfc.properties
13:46:42,725  INFO [installer] com.documentum.install.appserver.jboss.JbossApplicationServer - resolving $DOCUMENTUM_SHARED/wildfly9.0.1/server/DctmServer_MethodServer/deployments/bpm.ear/APP-INF/classes/log4j.properties
13:46:42,725  INFO [installer] com.documentum.install.appserver.jboss.JbossApplicationServer - resolving $DOCUMENTUM_SHARED/wildfly9.0.1/server/DctmServer_MethodServer/deployments/bpm.ear/bpm.war/WEB-INF/web.xml
13:46:42,727  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeInstallActions - Finished DctmActions.
13:46:44,885  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - Start to deploy dars for docbase: DocBase2
13:52:20,931  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - End to deploy dars for repository: DocBase2
13:52:20,932  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - Start to deploy dars for docbase: DocBase1
13:57:59,510  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - End to deploy dars for repository: DocBase1
13:57:59,511  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - Start to deploy dars for docbase: GR_DOCBASE
14:04:03,231  INFO [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - End to deploy dars for repository: GR_DOCBASE
14:04:03,268 ERROR [installer] com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars - Installation of DARs failed
com.documentum.install.shared.common.error.DiException: 3 DAR(s) failed to install.
        at com.documentum.install.shared.common.services.dar.DiDocAppFailureList.report(DiDocAppFailureList.java:39)
        at com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars.deployDars(DiPAPeProcessDars.java:123)
        at com.documentum.install.pe.installanywhere.actions.DiPAPeProcessDars.setup(DiPAPeProcessDars.java:71)
        at com.documentum.install.shared.installanywhere.actions.InstallWizardAction.install(InstallWizardAction.java:75)
        at com.zerog.ia.installer.actions.CustomAction.installSelf(Unknown Source)
        at com.zerog.ia.installer.InstallablePiece.install(Unknown Source)
        at com.zerog.ia.installer.InstallablePiece.install(Unknown Source)
        at com.zerog.ia.installer.GhostDirectory.install(Unknown Source)
        at com.zerog.ia.installer.InstallablePiece.install(Unknown Source)
        at com.zerog.ia.installer.Installer.install(Unknown Source)
        at com.zerog.ia.installer.actions.InstallProgressAction.ae(Unknown Source)
        at com.zerog.ia.installer.actions.ProgressPanelAction$1.run(Unknown Source)
14:04:03,269  INFO [installer]  - The INSTALLER_UI value is SWING
14:04:03,269  INFO [installer]  - The env PATH value is: /usr/xpg4/bin:$DOCUMENTUM_SHARED/java64/JAVA_LINK/bin:$DOCUMENTUM/product/7.3/bin:$DOCUMENTUM/dba:$ORACLE_HOME/bin:$DOCUMENTUM_SHARED/java64/JAVA_LINK/bin:$DOCUMENTUM/product/7.3/bin:$DOCUMENTUM/dba:$ORACLE_HOME/bin:$DOCUMENTUM/product/7.3/bin:$ORACLE_HOME/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/dmadmin/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
[dmadmin@content_server_01 ProcessEngine]$

 

It is mentioned that three DARs failed to be installed but since there are three docbases here, that’s actually one DAR per docbase. The only interesting information we can find from the install log file is that some DARs were installed properly so it’s not a generic issue but more likely an issue with one specific DAR. The next step is therefore to check the log file of the DAR installation:

[dmadmin@content_server_01 ProcessEngine]$ grep -i ERROR logs/dar_logs/GR_DOCBASE/peDars.log | grep -v "^\[INFO\].*ERROR"
[INFO]  dmbasic.exe output : dmbasic: Error 35 in line 585: Sub or Function not defined
[ERROR]  Unable to install dar file $DOCUMENTUM/product/7.3/install/DARsInternal/BPM.dar
com.emc.ide.installer.InstallException: Error handling controllable object Status = New; IsInstalled = true; com.emc.ide.artifact.bpm.model.bpm.impl.ActivityImpl@5e020dd1 (objectTypeName: null) (objectName: DB Inbound - Initiate, title: , subject: , authors: [], keywords: [], applicationType: , isHidden: false, compoundArchitecture: , componentLabel: [], resolutionLabel: , contentType: xml, versionLabel: [1.0, CURRENT], specialApp: DB-IN-IN.GIF, languageCode: , creatorName: null, archive: false, category: , controllingApp: , effectiveDate: [], effectiveFlag: [], effectiveLabel: [], expirationDate: [], extendedProperties: [], fullText: true, isSigned: false, isTemplate: false, lastReviewDate: null, linkResolved: false, publishFormats: [], retentionDate: null, status: , rootObject: true) (isPrivate: false, definitionState: installed, triggerThreshold: 0, triggerEvent: , execType: manual, execSubType: inbound_initiate, execMethodName: null, preTimer: 0, preTimerCalendarFlag: notusebusinesscal, preTimerRepeatLast: 0, postTimer: 0, postTimerCalendarFlag: notusebusinesscal, postTimerRepeatLast: 0, repeatableInvoke: true, execSaveResults: false, execTimeOut: 0, execErrHandling: stopAfterFailure, signOffRequired: false, resolveType: normal, resolvePkgName: , controlFlag: taskAssignedtoSupervisor, taskName: null, taskSubject: , performerType: user, performerFlag: noDeligationOrExtention, transitionMaxOutputCnt: 0, transitionEvalCnt: trigAllSelOutputLinks, transitionFlag: trigAllSelOutputLinks, transitionType: prescribed, execRetryMax: 0, execRetryInterval: 0, groupFlag: 0, template: true, artifactVersion: D65SP1);  Object ID = 4c0f123450002b1e;
Caused by: DfException:: THREAD: main; MSG: Error while making activity uneditable: com.emc.ide.artifactmanager.model.artifact.impl.ArtifactImpl@4bbc02ef (urn: urnd:com.emc.ide.artifact.bpm.activity/DB+Inbound+-+Initiate?location=%2FTemp%2FIntegration&name=DB+Inbound+-+Initiate, locale: null, repoLocation: null, categoryId: com.emc.ide.artifact.bpm.activity, implicitlyCreated: false, modifiedByUser: true); ERRORCODE: ff; NEXT: null
Caused by: DfException:: THREAD: main; MSG: [DM_WORKFLOW_E_NAME_NOT_EXIST]error:  "The dm_user object by the name 'dm_bps_inbound_user' specified in attribute performer_name does not exist."; ERRORCODE: 100; NEXT: null
[ERROR]  Failed to install DAR
Caused by: com.emc.ide.installer.InstallException: Error handling controllable object Status = New; IsInstalled = true; com.emc.ide.artifact.bpm.model.bpm.impl.ActivityImpl@5e020dd1 (objectTypeName: null) (objectName: DB Inbound - Initiate, title: , subject: , authors: [], keywords: [], applicationType: , isHidden: false, compoundArchitecture: , componentLabel: [], resolutionLabel: , contentType: xml, versionLabel: [1.0, CURRENT], specialApp: DB-IN-IN.GIF, languageCode: , creatorName: null, archive: false, category: , controllingApp: , effectiveDate: [], effectiveFlag: [], effectiveLabel: [], expirationDate: [], extendedProperties: [], fullText: true, isSigned: false, isTemplate: false, lastReviewDate: null, linkResolved: false, publishFormats: [], retentionDate: null, status: , rootObject: true) (isPrivate: false, definitionState: installed, triggerThreshold: 0, triggerEvent: , execType: manual, execSubType: inbound_initiate, execMethodName: null, preTimer: 0, preTimerCalendarFlag: notusebusinesscal, preTimerRepeatLast: 0, postTimer: 0, postTimerCalendarFlag: notusebusinesscal, postTimerRepeatLast: 0, repeatableInvoke: true, execSaveResults: false, execTimeOut: 0, execErrHandling: stopAfterFailure, signOffRequired: false, resolveType: normal, resolvePkgName: , controlFlag: taskAssignedtoSupervisor, taskName: null, taskSubject: , performerType: user, performerFlag: noDeligationOrExtention, transitionMaxOutputCnt: 0, transitionEvalCnt: trigAllSelOutputLinks, transitionFlag: trigAllSelOutputLinks, transitionType: prescribed, execRetryMax: 0, execRetryInterval: 0, groupFlag: 0, template: true, artifactVersion: D65SP1);  Object ID = 4c0f123450002b1e;
Caused by: DfException:: THREAD: main; MSG: Error while making activity uneditable: com.emc.ide.artifactmanager.model.artifact.impl.ArtifactImpl@4bbc02ef (urn: urnd:com.emc.ide.artifact.bpm.activity/DB+Inbound+-+Initiate?location=%2FTemp%2FIntegration&name=DB+Inbound+-+Initiate, locale: null, repoLocation: null, categoryId: com.emc.ide.artifact.bpm.activity, implicitlyCreated: false, modifiedByUser: true); ERRORCODE: ff; NEXT: null
Caused by: DfException:: THREAD: main; MSG: [DM_WORKFLOW_E_NAME_NOT_EXIST]error:  "The dm_user object by the name 'dm_bps_inbound_user' specified in attribute performer_name does not exist."; ERRORCODE: 100; NEXT: null
[dmadmin@content_server_01 ProcessEngine]$

 

With the above, we know that the only failed DAR is the BPM.dar and it looks like we have the reason for this: the DAR needs a user named “dm_bps_inbound_user” to proceed with the installation but couldn’t find it and therefore the installation failed. But actually that’s not the root cause, it’s only a consequence. The real reason why the DAR installation failed is displayed in the first line above.

[INFO]  dmbasic.exe output : dmbasic: Error 35 in line 585: Sub or Function not defined

 

For some reason, a function couldn’t be executed because not defined properly. This function is the one that is supposed to create the “dm_bps_inbound_user” user but with a CS 7.3 this function cannot be executed properly. As a result, the user isn’t created and then the DAR installation fail. For more information, you can refer to the BPM-11223.

 

This issue will – according to EMC – not be fixed in any patch of the xCP 2.3, even if this issue has been spotted quickly after the release of the xCP 2.3. Therefore, if you want to avoid this issue, you will have to wait several months for the xCP 2.4 to be released (not really realistic ;)) or you will need to create this user manually before installing the xCP 2.3 on a CS 7.3. You don’t need special permissions for this user and you don’t need to know its password so it’s rather simple to create it for all installed docbases in a few simple commands:

[dmadmin@content_server_01 ProcessEngine]$ echo "?,c,select r_object_id, user_name, user_login_name from dm_user where user_login_name like 'dm_bps%';" > create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "create,c,dm_user" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "set,c,l,user_name" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "dm_bps_inbound_user" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "set,c,l,user_login_name" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "dm_bps_inbound_user" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "save,c,l" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$ echo "?,c,select r_object_id, user_name, user_login_name from dm_user where user_login_name like 'dm_bps%';" >> create_user.api
[dmadmin@content_server_01 ProcessEngine]$
[dmadmin@content_server_01 ProcessEngine]$ cat create_user.api
?,c,select r_object_id, user_name, user_login_name from dm_user where user_login_name like 'dm_bps%';
create,c,dm_user
set,c,l,user_name
dm_bps_inbound_user
set,c,l,user_login_name
dm_bps_inbound_user
save,c,l
?,c,select r_object_id, user_name, user_login_name from dm_user where user_login_name like 'dm_bps%';
[dmadmin@content_server_01 ProcessEngine]$
[dmadmin@content_server_01 ProcessEngine]$
[dmadmin@content_server_01 ProcessEngine]$ sep="***********************"
[dmadmin@content_server_01 ProcessEngine]$ for docbase in `cd $DOCUMENTUM/dba/config; ls`;do echo;echo "$sep";echo "Create User: ${docbase}";echo "$sep";iapi ${docbase} -Udmadmin -Pxxx -Rcreate_user.api;done

***********************
Create User: GR_DOCBASE
***********************


        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0000.0205


Connecting to Server using docbase GR_DOCBASE
[DM_SESSION_I_SESSION_START]info:  "Session 010f12345001c734 started for user dmadmin."


Connected to Documentum Server running Release 7.3.0000.0214  Linux64.Oracle
Session id is s0
API> r_object_id     user_name             user_login_name                                                                                                                                                             
-------------------  --------------------- ---------------------

(0 row affected)

API> ...
110f12345000093c
API> SET> ...
OK
API> SET> ...
OK
API> ...
OK
API> r_object_id     user_name             user_login_name                                                                                                                                                             
-------------------  --------------------- ---------------------
110f12345000093c     dm_bps_inbound_user   dm_bps_inbound_user
(1 row affected)

API> Bye

***********************
Create User: DocBase1
***********************


        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0000.0205


Connecting to Server using docbase DocBase1
[DM_SESSION_I_SESSION_START]info:  "Session 010f234560052632 started for user dmadmin."


Connected to Documentum Server running Release 7.3.0000.0214  Linux64.Oracle
Session id is s0
API> r_object_id     user_name             user_login_name                                                                                                                                                             
-------------------  --------------------- ---------------------

(0 row affected)

API> ...
110f234560001532
API> SET> ...
OK
API> SET> ...
OK
API> ...
OK
API> r_object_id     user_name             user_login_name                                                                                                                                                             
-------------------  --------------------- ---------------------
110f234560001532     dm_bps_inbound_user   dm_bps_inbound_user                                                                                                                                                            
(1 row affected)

API> Bye

***********************
Create User: DocBase2
***********************


        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0000.0205


Connecting to Server using docbase DocBase2
[DM_SESSION_I_SESSION_START]info:  "Session 010f345670052632 started for user dmadmin."


Connected to Documentum Server running Release 7.3.0000.0214  Linux64.Oracle
Session id is s0
API> r_object_id     user_name             user_login_name                                                                                                                                                             
-------------------  --------------------- ---------------------

(0 row affected)

API> ...
110f345670001532
API> SET> ...
OK
API> SET> ...
OK
API> ...
OK
API> r_object_id     user_name             user_login_name                                                                                                                                                             
-------------------  --------------------- ---------------------
110f345670001532     dm_bps_inbound_user   dm_bps_inbound_user                                                                                                                                                            
(1 row affected)

API> Bye
[dmadmin@content_server_01 ProcessEngine]$
[dmadmin@content_server_01 ProcessEngine]$ rm create_user.api
[dmadmin@content_server_01 ProcessEngine]$

 

The users have been created properly in all docbases so just restart the xCP installer and this time the BPM.dar installation will succeed.

 

 

Cet article Documentum – Unable to install xCP 2.3 on a CS 7.3 est apparu en premier sur Blog dbi services.

Documentum – CS 7.3 – Issue with dmqdocbroker

$
0
0

Beginning of this month, I was building a new environment in 7.3 P05 (using silent installation but this isn’t relevant here) and I found a strange behaviour from the dmqdocbroker so I wanted to share that. You will see below an error message “Input has special characters …”. This is specific to the CS 7.3 for which we opened a SR with EMC/OTX some months ago (beginning of this year during the first CS 7.3 tests we performed) but the outcome of this SR was that this shouldn’t have any impact on the proper behaviour of the docbroker so I didn’t blog about it back then but now, it might very well be linked to the issue I will discuss here.

 

So let’s talk about the issue with the dmqdocbroker. In this new environment, we configured several docbases and several docbrokers so that we can have separated applications. I will create another blog related to the projections (with another issue) so here I’m directly getting to the point. The issue I faced is that the first (default) docbroker was working properly, responding to the ping, listing all docbases, aso… But then when I created two additional docbrokers, these two docbrokers weren’t behaving in the same way…

 

To show that, I can simply execute the ping or getdocbasemap command for each docbrokers (for this example, I will use the following ports: first docbroker on 1489/1490, second one on 1491/1492, third one on 1493/1494). We are always using secure communications so that’s why you will always see the secure port below in the replies:

[dmadmin@content-server-01 ~]$ dmqdocbroker -p 1489 -c ping
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Targeting current host
$DM_HOME/bin/dmawk: Input has special characters ...
 source line number 624
Using specified port: 1489
Successful reply from docbroker at host (content-server-01) on port(1490) running software version (7.3.0050.0039  Linux64).
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$ dmqdocbroker -p 1491 -c ping
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Targeting current host
$DM_HOME/bin/dmawk: Input has special characters ...
 source line number 624
Using specified port: 1491
dmqdocbroker: Error returned from docbroker request:
[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker ":1491" failed

[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker ":1491" failed

[DM_SESSION_E_RPC_ERROR]error:  "Server communication failure"

java.net.ConnectException: Connection refused

[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$ dmqdocbroker -p 1493 -c ping
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Targeting current host
$DM_HOME/bin/dmawk: Input has special characters ...
 source line number 624
Using specified port: 1493
dmqdocbroker: Error returned from docbroker request:
[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker ":1493" failed

[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker ":1493" failed

[DM_SESSION_E_RPC_ERROR]error:  "Server communication failure"

java.net.ConnectException: Connection refused

[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$

 

As you can see, the request to the docbroker “:<port>” failed… But wait, why is there only the port here? Why is the hostname not mentioned in the error message? Well, that’s a pretty good question! For an unknown reason, the request to the first docbroker is working properly (ping successful) but then the request to the two others isn’t. It’s just like if the hostname was known for the first one but not for the others…

 

So since it is possible to specify which host to target, then what happen if you specify that?

[dmadmin@content-server-01 ~]$ echo `hostname -f`
content-server-01
[dmadmin@content-server-01 ~]$ 
[dmadmin@content-server-01 ~]$ dmqdocbroker -t `hostname -f` -p 1489 -c ping
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Using specified port: 1489
Successful reply from docbroker at host (content-server-01) on port(1490) running software version (7.3.0050.0039  Linux64).
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$ dmqdocbroker -t `hostname -f` -p 1491 -c ping
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Using specified port: 1491
Successful reply from docbroker at host (content-server-01) on port(1492) running software version (7.3.0050.0039  Linux64).
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$ dmqdocbroker -t `hostname -f` -p 1493 -c ping
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Using specified port: 1493
Successful reply from docbroker at host (content-server-01) on port(1494) running software version (7.3.0050.0039  Linux64).
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$

 

And here all three docbrokers are replying successfully… And in case you didn’t notice, even the message “Input has special characters …” isn’t displayed here. So for me, this shows that this message might very well be linked to this particular behaviour.

 

I’m not 100% sure what the issue is (I didn’t get time to open a SR for this yet) but if I had to guess, I would suggest you to read carefully the next blogs I will post today because this issue might be linked by the dash (‘-‘) (<– no this isn’t a smiley!) in the hostname.

 

I only showed the ping above but I can reproduce the same behaviour with the getdocbasemap for example:

[dmadmin@content-server-01 ~]$ dmqdocbroker -p 1493 -c getdocbasemap
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Targeting current host
$DM_HOME/bin/dmawk: Input has special characters ...
 source line number 624
Using specified port: 1493
dmqdocbroker: Error returned from docbroker request:
[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker ":1493" failed

[DFC_DOCBROKER_REQUEST_FAILED] Request to Docbroker ":1493" failed

[DM_SESSION_E_RPC_ERROR]error:  "Server communication failure"

java.net.ConnectException: Connection refused

[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$
[dmadmin@content-server-01 ~]$ dmqdocbroker -t `hostname -f` -p 1493 -c getdocbasemap
dmqdocbroker: A DocBroker Query Tool
dmqdocbroker: Documentum Client Library Version: 7.3.0040.0025
Using specified port: 1493
**************************************************
**     D O C B R O K E R    I N F O             **
**************************************************
Docbroker host            : content-server-01
Docbroker port            : 1494
Docbroker network address : INET_ADDR: 03 52f 91f62f98 content-server-01 156.174.191.17
Docbroker version         : 7.3.0050.0039  Linux64
**************************************************
**     D O C B A S E   I N F O                  **
**************************************************
--------------------------------------------
Docbase name        : DocBase1
Docbase id          : 1000002
Docbase description : DocBase1 Repository
Govern docbase      :
Federation name     :
Server version      : 7.3.0050.0039  Linux64.Oracle
Docbase Roles       :
Docbase Dormancy Status     :
--------------------------------------------
Docbase name        : GR_DocBase
Docbase id          : 1000001
Docbase description : GR_DocBase Repository
Govern docbase      :
Federation name     :
Server version      : 7.3.0050.0039  Linux64.Oracle
Docbase Roles       : Global Registry
Docbase Dormancy Status     :
--------------------------------------------
[dmadmin@content-server-01 ~]$

 

If you don’t see this issue with a hostname that doesn’t contain any dash, please let me know! This would confirm that both issues are linked to that… As mentioned earlier, you will see in the next blog why I think this has something to do with the dash ;).

 

 

Cet article Documentum – CS 7.3 – Issue with dmqdocbroker est apparu en premier sur Blog dbi services.

Documentum – RCS 7.3 – dm_server_config cannot contain dash

$
0
0

As mentioned in this blog, I was recently installing a new 7.3 P05 environment. Actually, this environment was in HA and it was the first silent installation of a Remote Content Server for me. I already created a lot of blogs related to issues with the CS 7.3 but since this was my first RCS 7.3 installation, I was kind of expecting to face some issues… I wasn’t disappointed!

 

So let’s start with the first issue I faced during the creation of the Content-File Server (CFS) on the Remote Content Server. As always, I prepared the properties file with all the needed information for a RCS (the properties file isn’t the same as for a normal docbase creation on the Primary CS) and then I launched the process to install the CFS in silent for my Global Registry. After only 30 seconds or so, the installation was “done” so I knew something wasn’t right… When you install a CFS, if there is no docbroker present on the host, it will install one before creating the docbase… Please note that below, the docbroker was already created using a previous silent script so here, I’m just trying to create the CFS.

 

The problem with the silent installation is that if something goes wrong, you absolutely have no feedback… Using the GUI, you always have a message (more or less meaningful) printed on the screen so you know something wasn’t right and you can start checking why. So as a best practice, I would recommend to always check the installation log file for errors when using the silent installation.

 

So what is printed in the installation log file? (don’t look at the first WARN message, it’s because there is no global registry locally, yet)

[dmadmin@content-server-02 ~]$ cd $DM_HOME/install/logs
[dmadmin@content-server-02 logs]$ cat install.log
10:57:51,620  INFO [main] com.documentum.install.shared.installanywhere.actions.InitializeSharedLibrary - Done InitializeSharedLibrary ...
10:57:51,640  INFO [main] com.documentum.install.multinode.cfs.installanywhere.actions.DiWAServerCfsInitializeImportantServerVariables - The installer is gathering system configuration information.
10:57:51,651  INFO [main] com.documentum.install.server.installanywhere.actions.DiWASilentRemoteServerValidation - Start to verify the password
10:57:52,088  INFO [main] com.documentum.fc.client.security.impl.JKSKeystoreUtilForDfc - keystore file name is /tmp/104190.tmp/dfc.keystore
10:57:52,445  INFO [main] com.documentum.fc.client.security.internal.CreateIdentityCredential$MultiFormatPKIKeyPair - generated RSA (2,048-bit strength) mutiformat key pair in 334 ms
10:57:52,473  INFO [main] com.documentum.fc.client.security.internal.CreateIdentityCredential - certificate created for DFC <CN=dfc_q5Dd2d8FbuDOh98h1Ef2aeEcp3a,O=EMC,OU=Documentum> valid from Thu Sep 7 10:52:52 UTC 2017 to Sun Sep 5 10:57:52 UTC 2027:

10:57:52,474  INFO [main] com.documentum.fc.client.security.impl.JKSKeystoreUtilForDfc - keystore file name is /tmp/104190.tmp/dfc.keystore
10:57:52,485  INFO [main] com.documentum.fc.client.security.impl.InitializeKeystoreForDfc - [DFC_SECURITY_IDENTITY_INITIALIZED] Initialized new identity in keystore, DFC alias=dfc, identity=dfc_q5Dd2d8FbuDOh98h1Ef2aeEcp3a
10:57:52,486  INFO [main] com.documentum.fc.client.security.impl.AuthenticationMgrForDfc - identity for authentication is dfc_q5Dd2d8FbuDOh98h1Ef2aeEcp3a
10:57:52,490  INFO [main] com.documentum.fc.impl.RuntimeContext - DFC Version is 7.3.0040.0025
10:57:52,504  INFO [Timer-2] com.documentum.fc.client.impl.bof.cache.ClassCacheManager$CacheCleanupTask - [DFC_BOF_RUNNING_CLEANUP] Running class cache cleanup task
10:57:52,512  WARN [main] com.documentum.fc.client.security.internal.RegistrationMgr - [DFC_SECURITY_GR_PUBLICATION_FAILED] Publication of DFC instance with global registry failed
DfException:: THREAD: main; MSG: [DFC_BOF_GLOBAL_REGISTRY_NOT_CONFIGURED] A global registry is not configured; ERRORCODE: ff; NEXT: null
        at com.documentum.fc.client.security.impl.DfcIdentityPublisher.<init>(DfcIdentityPublisher.java:51)
        ...
        at com.zerog.lax.LAX.main(Unknown Source)
10:57:52,955  INFO [main] com.documentum.fc.client.impl.connection.docbase.DocbaseConnection - Object protocol version 2
10:57:52,984  INFO [main] com.documentum.fc.client.security.internal.AuthenticationMgr - new identity bundle <dfc_q5Dd2d8FbuDOh98h1Ef2aeEcp3a  1602102952       content-server-02         hudL6VVqhfy1whQlqbqfn3xZoOlola5zscimwba4o0MDQbigdzAOi+l54BHFvqc/3auMipaihywp65a5bR4vqvzP55CzzuFjSD+UZa3vJOGiwpKlctdmg45Kl0aOTwrfYH5jEupQ79oUVNY1cNQmAxn3odYFwguvaEp3VxezAbO+cPh8svnKjhvZJm/DFVrmdLnGPu+PHf3jWHbYSfhc+TWDLPqk8dlFTzJTjLnGLnGPu+PHf3jWHbYSfhc+TWDLPqk/13OmxsnXcSUL59QbhU+BBW2/4lsXvSvwxP/8A+/GKsGPSLoTFZJ2nlbJnq0TX5XWPTAG7Emgjeil35cbfax6D/rUQp8kHWPlLWtPvpOaKQ==>
10:57:54,477  INFO [main] com.documentum.fc.client.impl.connection.docbase.DocbaseConnection - Object protocol version 2
10:57:54,526  INFO [main] com.documentum.install.server.installanywhere.actions.DiWASilentRemoteServerValidation - Server config object name is invalid
10:57:54,526 ERROR [main] com.documentum.install.server.installanywhere.actions.DiWASilentRemoteServerValidation - Server config name only can contain characters: A-Z, a-z, 0-9, underscore(_) and dot(.)
com.documentum.install.shared.common.error.DiException: Server config name only can contain characters: A-Z, a-z, 0-9, underscore(_) and dot(.)
        at com.documentum.install.server.installanywhere.actions.DiWASilentRemoteServerValidation.setup(DiWASilentRemoteServerValidation.java:82)
        at com.documentum.install.shared.installanywhere.actions.InstallWizardAction.install(InstallWizardAction.java:75)
        at com.zerog.ia.installer.actions.CustomAction.installSelf(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.an(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.am(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runNextInstallPiece(Unknown Source)
        at com.zerog.ia.installer.ConsoleBasedAAMgr.ac(Unknown Source)
        at com.zerog.ia.installer.AAMgrBase.runPreInstall(Unknown Source)
        at com.zerog.ia.installer.LifeCycleManager.consoleInstallMain(Unknown Source)
        at com.zerog.ia.installer.LifeCycleManager.executeApplication(Unknown Source)
        at com.zerog.ia.installer.Main.main(Unknown Source)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.zerog.lax.LAX.launch(Unknown Source)
        at com.zerog.lax.LAX.main(Unknown Source)
10:57:54,527  INFO [main]  - The INSTALLER_UI value is SILENT
10:57:54,527  INFO [main]  - The KEEP_TEMP_FILE value is true
10:57:54,527  INFO [main]  - The common.installOwner.password value is ******
10:57:54,527  INFO [main]  - The SERVER.SECURE.ROOT_PASSWORD value is ******
10:57:54,527  INFO [main]  - The common.upgrade.aek.lockbox value is null
10:57:54,527  INFO [main]  - The common.old.aek.passphrase.password value is null
10:57:54,527  INFO [main]  - The common.aek.algorithm value is AES_256_CBC
10:57:54,527  INFO [main]  - The common.aek.passphrase.password value is ******
10:57:54,527  INFO [main]  - The common.aek.key.name value is CSaek
10:57:54,527  INFO [main]  - The common.use.existing.aek.lockbox value is null
10:57:54,528  INFO [main]  - The SERVER.ENABLE_LOCKBOX value is true
10:57:54,528  INFO [main]  - The SERVER.LOCKBOX_FILE_NAME value is lockbox.lb
10:57:54,528  INFO [main]  - The SERVER.LOCKBOX_PASSPHRASE.PASSWORD value is ******
10:57:54,528  INFO [main]  - The SERVER.COMPONENT_ACTION value is CREATE
10:57:54,528  INFO [main]  - The SERVER.DOCBROKER_ACTION value is null
10:57:54,528  INFO [main]  - The SERVER.PRIMARY_CONNECTION_BROKER_HOST value is content-server-01
10:57:54,528  INFO [main]  - The SERVER.PRIMARY_CONNECTION_BROKER_PORT value is 1489
10:57:54,528  INFO [main]  - The SERVER.PROJECTED_CONNECTION_BROKER_HOST value is content-server-02
10:57:54,528  INFO [main]  - The SERVER.PROJECTED_CONNECTION_BROKER_PORT value is 1489
10:57:54,528  INFO [main]  - The SERVER.FQDN value is content-server-02
10:57:54,528  INFO [main]  - The SERVER.DOCBASE_NAME value is GR_DocBase
10:57:54,528  INFO [main]  - The SERVER.PRIMARY_SERVER_CONFIG_NAME value is GR_DocBase
10:57:54,528  INFO [main]  - The SERVER.REPOSITORY_USERNAME value is dmadmin
10:57:54,528  INFO [main]  - The SERVER.SECURE.REPOSITORY_PASSWORD value is ******
10:57:54,528  INFO [main]  - The SERVER.REPOSITORY_USER_DOMAIN value is
10:57:54,529  INFO [main]  - The SERVER.REPOSITORY_USERNAME_WITH_DOMAIN value is dmadmin
10:57:54,529  INFO [main]  - The SERVER.REPOSITORY_HOSTNAME value is content-server-01
10:57:54,529  INFO [main]  - The SERVER.CONNECTION_BROKER_NAME value is null
10:57:54,529  INFO [main]  - The SERVER.CONNECTION_BROKER_PORT value is null
10:57:54,529  INFO [main]  - The SERVER.DOCBROKER_NAME value is
10:57:54,529  INFO [main]  - The SERVER.DOCBROKER_PORT value is
10:57:54,529  INFO [main]  - The SERVER.DOCBROKER_CONNECT_MODE value is null
10:57:54,529  INFO [main]  - The SERVER.USE_CERTIFICATES value is false
10:57:54,529  INFO [main]  - The SERVER.DOCBROKER_KEYSTORE_FILE_NAME value is null
10:57:54,529  INFO [main]  - The SERVER.DOCBROKER_KEYSTORE_PASSWORD_FILE_NAME value is null
10:57:54,529  INFO [main]  - The SERVER.DOCBROKER_CIPHER_LIST value is null
10:57:54,529  INFO [main]  - The SERVER.DFC_SSL_TRUSTSTORE value is null
10:57:54,529  INFO [main]  - The SERVER.DFC_SSL_TRUSTSTORE_PASSWORD value is ******
10:57:54,529  INFO [main]  - The SERVER.DFC_SSL_USE_EXISTING_TRUSTSTORE value is null
10:57:54,529  INFO [main]  - The SERVER.CONNECTION_BROKER_SERVICE_STARTUP_TYPE value is null
10:57:54,529  INFO [main]  - The SERVER.DOCUMENTUM_DATA value is $DOCUMENTUM/data
10:57:54,530  INFO [main]  - The SERVER.DOCUMENTUM_SHARE value is $DOCUMENTUM/share
10:57:54,530  INFO [main]  - The CFS_SERVER_CONFIG_NAME value is content-server-02_GR_DocBase
10:57:54,530  INFO [main]  - The SERVER.DOCBASE_SERVICE_NAME value is GR_DocBase
10:57:54,530  INFO [main]  - The CLIENT_CERTIFICATE value is null
10:57:54,530  INFO [main]  - The RKM_PASSWORD value is ******
10:57:54,530  INFO [main]  - The SERVER.DFC_BOF_GLOBAL_REGISTRY_VALIDATE_OPTION_IS_SELECTED value is true
10:57:54,530  INFO [main]  - The SERVER.PROJECTED_DOCBROKER_PORT_OTHER value is 1489
10:57:54,530  INFO [main]  - The SERVER.PROJECTED_DOCBROKER_HOST_OTHER value is content-server-01
10:57:54,530  INFO [main]  - The SERVER.GLOBAL_REGISTRY_REPOSITORY value is GR_DocBase
10:57:54,530  INFO [main]  - The SERVER.BOF_REGISTRY_USER_LOGIN_NAME value is dm_bof_registry
10:57:54,530  INFO [main]  - The SERVER.SECURE.BOF_REGISTRY_USER_PASSWORD value is ******
10:57:54,530  INFO [main]  - The SERVER.COMPONENT_ACTION value is CREATE
10:57:54,530  INFO [main]  - The SERVER.COMPONENT_NAME value is null
10:57:54,530  INFO [main]  - The SERVER.DOCBASE_NAME value is GR_DocBase
10:57:54,531  INFO [main]  - The SERVER.CONNECTION_BROKER_NAME value is null
10:57:54,531  INFO [main]  - The SERVER.CONNECTION_BROKER_PORT value is null
10:57:54,531  INFO [main]  - The SERVER.PROJECTED_CONNECTION_BROKER_HOST value is content-server-02
10:57:54,531  INFO [main]  - The SERVER.PROJECTED_CONNECTION_BROKER_PORT value is 1489
10:57:54,531  INFO [main]  - The SERVER.PRIMARY_SERVER_CONFIG_NAME value is GR_DocBase
10:57:54,531  INFO [main]  - The SERVER.DOCBROKER_NAME value is
10:57:54,531  INFO [main]  - The SERVER.DOCBROKER_PORT value is
10:57:54,531  INFO [main]  - The SERVER.CONNECTION_BROKER_SERVICE_STARTUP_TYPE value is null
10:57:54,531  INFO [main]  - The SERVER.REPOSITORY_USERNAME value is dmadmin
10:57:54,531  INFO [main]  - The SERVER.REPOSITORY_PASSWORD value is ******
10:57:54,531  INFO [main]  - The SERVER.REPOSITORY_USER_DOMAIN value is
10:57:54,531  INFO [main]  - The SERVER.REPOSITORY_USERNAME_WITH_DOMAIN value is dmadmin
10:57:54,531  INFO [main]  - The SERVER.DFC_BOF_GLOBAL_REGISTRY_VALIDATE_OPTION_IS_SELECTED_KEY value is null
10:57:54,531  INFO [main]  - The SERVER.PROJECTED_DOCBROKER_PORT_OTHER value is 1489
10:57:54,531  INFO [main]  - The SERVER.PROJECTED_DOCBROKER_HOST_OTHER value is content-server-01
10:57:54,531  INFO [main]  - The SERVER.GLOBAL_REGISTRY_REPOSITORY value is GR_DocBase
10:57:54,532  INFO [main]  - The SERVER.BOF_REGISTRY_USER_LOGIN_NAME value is dm_bof_registry
10:57:54,532  INFO [main]  - The SERVER.SECURE.BOF_REGISTRY_USER_PASSWORD value is ******
10:57:54,532  INFO [main]  - The SERVER.COMPONENT_ACTION value is CREATE
10:57:54,532  INFO [main]  - The SERVER.COMPONENT_NAME value is null
10:57:54,532  INFO [main]  - The SERVER.PRIMARY_SERVER_CONFIG_NAME value is GR_DocBase
10:57:54,532  INFO [main]  - The SERVER.DOCBASE_NAME value is GR_DocBase
10:57:54,532  INFO [main]  - The SERVER.REPOSITORY_USERNAME value is dmadmin
10:57:54,532  INFO [main]  - The SERVER.REPOSITORY_PASSWORD value is ******
10:57:54,532  INFO [main]  - The SERVER.REPOSITORY_USER_DOMAIN value is
10:57:54,532  INFO [main]  - The SERVER.REPOSITORY_USERNAME_WITH_DOMAIN value is dmadmin
10:57:54,532  INFO [main]  - The env PATH value is: /usr/xpg4/bin:$JAVA_HOME/bin:$DM_HOME/bin:$DOCUMENTUM/dba:$ORACLE_HOME/bin:$JAVA_HOME/bin:$DM_HOME/bin:$DOCUMENTUM/dba:$ORACLE_HOME/bin:$DM_HOME/bin:$ORACLE_HOME/bin:/usr/lib64/qt-3.3/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/dmadmin/bin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin
[dmadmin@content-server-02 logs]$

 

As you can see above, the installation fails because the properties aren’t “correct”. More specifically, the installation fails because the dm_server_config name provided doesn’t match the requirement/validation… Starting with the CS 7.3 GA release, the Content Server team introduced a new validation which force the dm_server_config name to only contains letters (lower/upper case), numbers, underscore or dot. If you are familiar with the Remote Content Servers, you should know that by default, the CFS installation will create a new dm_server_config object with a name that is “<hostname>_<service_name>”. So if you are installing a CFS for a docbase “GR_DocBase” with a service name set to “GR_DocBase” (it’s not mandatory the same value as the docbase name) on a Content Server with a hostname equal to “content-server-02″, then the dm_server_config will, by default, have the following name: content-server-02_GR_DocBase.

 

So if you compare this default value with the one from the log file, you will see that it is the same… Because I knew what default value the GUI Installer would have chosen, I therefore put this value in the silent properties file so that we keep our naming conventions on all our environments (7.3 or not). So this is the default value that the installer would have chosen and yet the installation fails and this is all because the hostname contains a simple dash… Funny, isn’t it?

 

Since this is clearly an issue, I opened a SR with OTX to ask them to either:

  • Explain why the dash (‘-‘) aren’t accepted in the dm_server_config name and since this is the default value, where it is documented that the hostname of the Content Servers cannot contain any dashs
  • Provide a hotfix for this issue and fix it in the next patch as well

 

OTX obviously recognized that this validation is too strict and they are therefore working on providing us a hotfix (via CS-57533) and implementing a more reliable validation. At the moment, I got a first draft hotfix that only solve the silent installation part (so the issue is still present using the GUI). I’m pretty sure it won’t be hard for OTX to solve that also on the GUI and to include the fix in a next patch but I don’t know which one at the moment!

 

 

Cet article Documentum – RCS 7.3 – dm_server_config cannot contain dash est apparu en premier sur Blog dbi services.

Documentum – RCS 7.3 – Issue with projections

$
0
0

In the last two blogs I posted, I mentioned that I was working on silent installations with CS 7.3 (in HA). The issue I will describe in this blog is linked to the HA installation. I faced this issue using the silent installation but I’m guessing it should also occurs using the GUI Installation.

 

So basically on the first Content Server, I installed a Global Registry and a few other docbases. For the creation of the docbases, there were obviously a docbroker installed. This is the global docbroker which was targeted by default by all docbases using the server.ini. In addition to that, I installed 2 other docbrokers for specific docbases. The purpose here is to have the docbroker N°1 only for the GR + DocBase1 and the docbroker N°2 only for the GR + DocBase2 + DocBase3. So I started to configure the projections to achieve that goal.

 

I will use below the GR. If you followed what I mentioned above, I should see – at the end – two projections in the docbase (+ the default one from the server.ini). So let’s configure the projections (with only one Content Server installed):

[dmadmin@content-server-01 ~]$ iapi GR_DocBase
Please enter a user (dmadmin):
Please enter password for dmadmin:


        EMC Documentum iapi - Interactive API interface
        (c) Copyright EMC Corp., 1992 - 2016
        All rights reserved.
        Client Library Release 7.3.0040.0025


Connecting to Server using docbase GR_DocBase
[DM_SESSION_I_SESSION_START]info:  "Session 010f123450003d07 started for user dmadmin."


Connected to Documentum Server running Release 7.3.0050.0039  Linux64.Oracle
Session id is s0
API> retrieve,c,dm_server_config
...
3d0f123450000102
API> dump,c,l
...
USER ATTRIBUTES

  object_name                     : GR_DocBase
  title                           :
  ...
  projection_targets            []: <none>
  projection_ports              []: <none>
  projection_proxval            []: <none>
  projection_notes              []: <none>
  projection_enable             []: <none>
  ...
  i_vstamp                        : 28

API> ?,c,select projection_targets, projection_ports, projection_proxval, projection_notes, projection_enable from dm_server_config where r_object_id = '3d0f123450000102'
projection_targets         projection_ports  projection_proxval  projection_notes                   projection_enable
-------------------------  ----------------  ------------------  ---------------------------------  -----------------
                                                                                                    
                                                                                                    
(2 rows affected)

API> set,c,l,projection_targets[0]
SET> content-server-01
...
OK
API> set,c,l,projection_ports[0]
SET> 1493
...
OK
API> set,c,l,projection_proxval[0]
SET> 1
...
OK
API> set,c,l,projection_notes[0]
SET> Dedicated Docbroker N°2
...
OK
API> set,c,l,projection_enable[0]
SET> T
...
OK
API> save,c,l
...
OK
API> dump,c,l
...
USER ATTRIBUTES

  object_name                     : GR_DocBase
  ...
  projection_targets           [0]: content-server-01
  projection_ports             [0]: 1493
  projection_proxval           [0]: 1
  projection_notes             [0]: Dedicated Docbroker N°2
  projection_enable            [0]: T
  ...
  i_vstamp                        : 29

API> reinit,c
...
OK
API> ?,c,select projection_targets, projection_ports, projection_proxval, projection_notes, projection_enable from dm_server_config where r_object_id = '3d0f123450000102'
projection_targets         projection_ports  projection_proxval  projection_notes                   projection_enable
-------------------------  ----------------  ------------------  ---------------------------------  -----------------
                                                                                                    
content-server-01          1493              1                   Dedicated Docbroker N°2            1
(2 rows affected)

API> set,c,l,projection_targets[1]
SET> content-server-01
...
OK
API> set,c,l,projection_ports[1]
SET> 1491
...
OK
API> set,c,l,projection_proxval[1]
SET> 1
...
OK
API> set,c,l,projection_notes[1]
SET> Dedicated Docbroker N°1
...
OK
API> set,c,l,projection_enable[1]
SET> T
...
OK
API> save,c,l
...
OK
API> dump,c,l
...
USER ATTRIBUTES

  object_name                     : GR_DocBase
  ...
  projection_targets           [0]: content-server-01
                               [1]: content-server-01
  projection_ports             [0]: 1493
                               [1]: 1491
  projection_proxval           [0]: 1
                               [1]: 1
  projection_notes             [0]: Dedicated Docbroker N°2
                               [1]: Dedicated Docbroker N°1
  projection_enable            [0]: T
                               [1]: T
  ...
  i_vstamp                        : 30

API> reinit,c
...
OK
API> ?,c,select projection_targets, projection_ports, projection_proxval, projection_notes, projection_enable from dm_server_config where r_object_id = '3d0f123450000102'
projection_targets         projection_ports  projection_proxval  projection_notes                   projection_enable
-------------------------  ----------------  ------------------  ---------------------------------  -----------------
content-server-01          1491              1                   Dedicated Docbroker N°1            1
content-server-01          1493              1                   Dedicated Docbroker N°2            1
(2 rows affected)

 

Up to this point, everything sounds good and everything is working. If you try to access DA, you will see two projections for the Global Registry that are the two we defined above:

Projection1

 

So this is working. Now what is the goal of this blog? Well it’s not what is above… So let’s talk about the issue now! The next step in this environment was to set it in High Availability. As mentioned my last blog, I faced some issues with the Remote Content Server (RCS) installation but I was finally able to install a Content-File Server. When I finished the installation of GR_DocBase on the RCS, I wanted to setup the projections between the CS1 and CS2… For that, I opened DA again and I went to the same screen that you can see above (in the screenshot).

 

What I was expecting to see was the exact same thing as above, meaning two projections of the GR_DocBase with the two docbrokers installed on the CS1. What I saw was a little bit different…:

Projection2

 

I can assure you that between the two screenshots above, the only thing I did was to install the CFS for GR_DocBase on the RCS… So why is this screen not working anymore, what’s the issue? “An error has occurred. 1 >= 1″. Yeah sure, what else? ;)

 

I checked the Documentum Administrator logs and found the following stack trace:

05:45:07,980 ERROR [[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] com.documentum.web.common.Trace - 1 >= 1
java.lang.ArrayIndexOutOfBoundsException: 1 >= 1
        at java.util.Vector.elementAt(Vector.java:474)
        at com.documentum.fc.common.DfList.get(DfList.java:427)
        at com.documentum.fc.common.DfList.getString(DfList.java:561)
        at com.documentum.webcomponent.admin.server.ServerConnectionBrokerList.loadConnectionBrokerProjections(ServerConnectionBrokerList.java:78)
        at com.documentum.webcomponent.admin.server.ServerConnectionBrokerList.onInit(ServerConnectionBrokerList.java:51)
        at com.documentum.web.form.FormProcessor.invokeMethod(FormProcessor.java:1604)
        at com.documentum.web.form.FormProcessor.invokeMethod(FormProcessor.java:1489)
        at com.documentum.web.form.FormProcessor.fireOnInitEvent(FormProcessor.java:1154)
        at com.documentum.web.form.ControlTag.fireFormOnInitEvent(ControlTag.java:794)
        at com.documentum.web.formext.control.component.ComponentIncludeTag.renderEnd(ComponentIncludeTag.java:135)
        at com.documentum.web.form.ControlTag.doEndTag(ControlTag.java:928)
        at jsp_servlet._webcomponent._library._propertysheetwizardcontainer.__propertysheetwizardcontainer._jsp__tag25(__propertysheetwizardcontainer.java:1501)
        at jsp_servlet._webcomponent._library._propertysheetwizardcontainer.__propertysheetwizardcontainer._jspService(__propertysheetwizardcontainer.java:368)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:35)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:286)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260)
        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:350)
        at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
        at com.documentum.web.servlet.ResponseHeaderControlFilter.doFilter(ResponseHeaderControlFilter.java:351)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
        at com.documentum.web.servlet.CompressionFilter.doFilter(CompressionFilter.java:96)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
        at com.documentum.web.env.WDKController.processRequest(WDKController.java:144)
        at com.documentum.web.env.WDKController.doFilter(WDKController.java:131)
        at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:78)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3683)
        at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3649)
        at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:326)
        at weblogic.security.service.SecurityManager.runAsForUserCode(SecurityManager.java:197)
        at weblogic.servlet.provider.WlsSecurityProvider.runAsForUserCode(WlsSecurityProvider.java:203)
        at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:71)
        at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2433)
        at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2281)
        at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2259)
        at weblogic.servlet.internal.ServletRequestImpl.runInternal(ServletRequestImpl.java:1691)
        at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1651)
        at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:272)
        at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
        at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
        at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
        at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
        at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)

 

As mentioned in the stack trace (which is more useful than the error message), the problem might come from the docbrokers projections… But we were checking them just before installing the Remote docbase and it was OK… With the CS 7.3, the RCS installation is automatically adding a projection on the Primary Content Server dm_server_config object to point to the Remote docbroker and this is causing this error…

 

So I did check the projections on the GR_DocBase Primary dm_server_config object to see what was the issue and I got this:

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

  object_name                     : GR_DocBase
  ...
  projection_targets           [0]: content-server-01
                               [1]: content-server-01
                               [2]: content-server-02
  projection_ports             [0]: 1493
                               [1]: 1491
                               [2]: 1489
  projection_proxval           [0]: 1
                               [1]: 1
                               [2]: 2
  projection_notes             [0]: Dedicated Docbroker N°2
                               [1]: Dedicated Docbroker N°1
                               [2]: Projecting primary to remote.
  projection_enable            [0]: T
                               [1]: T
                               [2]: T
  ...
  i_vstamp                        : 34

API> reinit,c
...
OK
API> ?,c,select projection_targets, projection_ports, projection_proxval, projection_notes, projection_enable from dm_server_config where r_object_id = '3d0f123450000102'
projection_targets         projection_ports  projection_proxval  projection_notes                   projection_enable
-------------------------  ----------------  ------------------  ---------------------------------  -----------------
content-server-02          1489              2                   Projecting primary to remote.      1
content-server-01          1491              1                   Dedicated Docbroker N°1            1
content-server-01          1493              1                   Dedicated Docbroker N°2            1
(3 rows affected)

 

So this looks good isn’t it? And yet through DA, it shows this ArrayIndexOutOfBoundsException… I tried a lot of things but the only way I could solve this issue was by removing the projection that the RCS Installer is automatically adding and then adding it again… To simplify the process, I included that in our silent scripts so it is done automatically after the creation of the CFS. Just below is a very small extract of code I added in our silent scripts (shell) in order to remove the projection added by the installer (some variables are obviously defined before this section of code…):

...
echo "  **  "
echo "  **  HA Docbase Configuration - projections"
echo "  **  "
dql_select_docbase="${script_folder}/rcs_select_${docbase}"
dql_update_docbase="${script_folder}/rcs_update_${docbase}"
idql ${docbase} -U${install_owner} -Pxxx <<EOF > ${dql_select_docbase}.log 2>&1
SELECT 'projection_id=', i_position*-1-1 as projection_id FROM dm_server_config WHERE LOWER(object_name) like LOWER('${docbase}') AND projection_notes='Projecting primary to remote.' AND LOWER(projection_targets) like LOWER('%`hostname -s`%') enable(ROW_BASED)
go
EOF
if [[ ${?} != 0 ]]; then
  echo "ERROR - There was a problem while gathering the index for ${docbase}. Please see the file '${dql_select_docbase}.log' for error. Exiting."
  exit
fi
index=`grep "^projection_id=[[:space:]]" ${dql_select_docbase}.log | sed 's,^.*=[[:space:]]*\([0-9]*\)[[:space:]]*$,\1,'`
if [[ ${index} == "" || ${index} == '""' ]]; then
  echo "INFO - There is no existing projections from the primary to the remote."
else
  echo -e "INFO - The index of 'dm_server_config.projection_targets' is:  \t${index}"
idql ${docbase} -U${install_owner} -Pxxx <<EOF > ${dql_update_docbase}.log 2>&1
UPDATE dm_server_config object REMOVE projection_targets[${index}], REMOVE projection_ports[${index}], REMOVE projection_proxval[${index}], REMOVE projection_notes[${index}], REMOVE projection_enable[${index}] WHERE LOWER(object_name) like LOWER('${docbase}') enable(ROW_BASED)
go
EOF
  nb_error=`grep "_E_" ${dql_update_docbase}.log | wc -l`
  cat "${dql_update_docbase}.log"
  echo ""
  if [[ ${nb_error} != 0 ]]; then
    echo "ERROR - There was a problem while updating the object for ${docbase}. Please see above. Exiting."
    exit
  fi
fi
...

 

This small section of code is just to shows how this kind of things can be automated. I’m just executing a first DQL to gather the index of the projection added by the RCS installer. This is the correct index because the note added by the RCS is always “Projecting primary to remote.” and the target host is obviously the RCS… To confirm that DA is now working again, you can reload the docbroker projection screen and for me it was indeed working.

 

So then the next step is to add the projection again but this time without the “.” at the end of the note (to differentiate them) because we still need this projection for the CS2 to be aware of the docbases on the CS1. You can either do it programmatically using iapi/idql or with DA directly. After adding this third projection again, I got the following (notice the only difference is the “.” in the notes) in the docbase:

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

  object_name                     : GR_DocBase
  ...
  projection_targets           [0]: content-server-01
                               [1]: content-server-01
                               [2]: content-server-02
  projection_ports             [0]: 1493
                               [1]: 1491
                               [2]: 1489
  projection_proxval           [0]: 1
                               [1]: 1
                               [2]: 2
  projection_notes             [0]: Dedicated Docbroker N°2
                               [1]: Dedicated Docbroker N°1
                               [2]: Projecting primary to remote
  projection_enable            [0]: T
                               [1]: T
                               [2]: T
  ...
  i_vstamp                        : 36

API> reinit,c
...
OK
API> ?,c,select projection_targets, projection_ports, projection_proxval, projection_notes, projection_enable from dm_server_config where r_object_id = '3d0f123450000102'
projection_targets         projection_ports  projection_proxval  projection_notes                   projection_enable
-------------------------  ----------------  ------------------  ---------------------------------  -----------------
content-server-02          1489              2                   Projecting primary to remote       1
content-server-01          1491              1                   Dedicated Docbroker N°1            1
content-server-01          1493              1                   Dedicated Docbroker N°2            1
(3 rows affected)

 

The result is the same but I was finally able to see the three projections through DA… I don’t know what caused this error because I simply re-added the exact same thing with a different note (slightly) but I’m sure that this was caused by the RCS Installation…

Projection3

 

Yet another interesting behaviour of Documentum… So many ways to have fun! :)

 

 

Cet article Documentum – RCS 7.3 – Issue with projections est apparu en premier sur Blog dbi services.


Documentum: IndexAgent uninstalled continues to queue requests

$
0
0

We had a strange behavior by a customer regarding the indexing queue. We used to have two IA configured and we uninstalled one.
I figured out that we still had indexing queue requests for the old index agent while it was totally uninstalled.

I checked the following objects to see if the agent was still configured somewhere: dm_fulltext_index, dm_ftengine_config, dm_ftindex_agent_config. But the old IA was not declared anymore.

The main problem is that it continued to queue all changes in the indexing queue and nothing cleaned it up, so we got like 2 million requests, filling up the db table.

I finally found out where the old IA was declared: in the registry events.
select * from dmi_registry where user_name = ‘dm_fulltext_index_user_01′;

r_object_id          user_name                     registered_id        event
2601b86480001d03     dm_fulltext_index_user_01     0301b86480000104     dm_save
2601b86480001d04     dm_fulltext_index_user_01     0301b86480000104     dm_destroy
2601b86480001d05     dm_fulltext_index_user_01     0301b86480000105     dm_save
2601b86480001d06     dm_fulltext_index_user_01     0301b86480000105     dm_readonlysave
2601b86480001d07     dm_fulltext_index_user_01     0301b86480000105     dm_checkin
...

In order to unregister the events, use the following:
unregister,c,<registered_id>,<event>,<queue_name>

So for me:

unregister,c,0301b86480000104,dm_save,dm_fulltext_index_user_01
unregister,c,0301b86480000104,dm_destroy,dm_fulltext_index_user_01
unregister,c,0301b86480000105,dm_save,dm_fulltext_index_user_01
unregister,c,0301b86480000105,dm_readonlysave,dm_fulltext_index_user_01
...

If you want to check if the old IA still queues requests, you can use:
select distinct name from dmi_queue_item where name like ‘dm_fulltext%';

If you see the old queue name, that means you still have the registered events.

 

Cet article Documentum: IndexAgent uninstalled continues to queue requests est apparu en premier sur Blog dbi services.

Enable Trusted Content Services (TCS) license in Documentum Content Server

$
0
0

The Trusted Content Services is a pack of features that you can enable/purchase to gain more security for your Content Server. The main key features are listed in this documentation:

https://www.emc.com/collateral/software/data-sheet/h3138-security-ds.pdf

In our case, we wanted to benefit from the Repository Encryption feature:

Repository Encryption: Documentum TCS prevents intruders from accessing information even if they obtain unauthorized access to repository files at the file-system or storage level. This capability protects content against an operating system level security breach and enables you to securely store back-up media containing information assets in encrypted form.

To enable the TCS first you must get a license key from OpenText then they will send you a key String. Put that key only in a file located here: $DOCUMENTUM/dba/tcs_license

Then login to the docbase with IAPI and enable TCS for this repo with:

retrieve,c,dm_server_config
set,c,l,r_trusted_mode
1
save,c,l
reinit,c

No need to restart, the TCS license is only checked dynamically when a TCS feature is called.
To see if the license has been properly integrated, login to Documentum Administrator and on the Admin page you should see:
Trusted Mode: Enabled

 

Cet article Enable Trusted Content Services (TCS) license in Documentum Content Server est apparu en premier sur Blog dbi services.

Documentum – Unable to configure IDS 7.3 for a docbase

$
0
0

In this blog, I will talk about an issue with the IDS 7.3 which is installed on a Content Server 7.3. The IDS is the Interactive Delivery Services. It is a product provided by OpenText that needs to be installed on a Content Server (for the “Source” part) and on a Target Server (for the “Target” part). The IDS can be used to publish content from a Documentum repository to a target machine for use in another application or something like that.

 

When installing/configuring an IDS, there are several things to do:

  1. Install the Source + patch if needed
  2. Configure a docbase on the Source (basically install DARs)
  3. Install the Target + patch if needed
  4. Configure a docbase on the Target (basically setup of an agent which will use a DB + file system for the exported documents)

 

In this blog, I will only talk about an issue which will occur if you try to execute the step 2 with an IDS 7.3 on a Content Server 7.3. Once the IDS is installed and patched (if needed), you can configure a docbase using the config.bin file:

[dmadmin@content_server_01 ~]$ cd $DM_HOME/webcache/install/
[dmadmin@content_server_01 install]$ 
[dmadmin@content_server_01 install]$ ./config.bin

 

On the IDS Source Configurator, you just have to select the docbase you want to configure and it will start the configuration of the docbase. As mentioned above, the main thing it is doing is to install the DARs that are placed under “$DM_HOME/webcache/install/SCSDar/”. For that purpose, it will use the Headless Composer. When you do that, an error message will be printed saying the following:

DiWAWebcsConfigureDocbase failed! - Could not deploy $DM_HOME/webcache/install/SCSDar/SCSDocApp.dar.
 Please check dar installation log file $DM_HOME/webcache/install/SCSDar/DocBase1_SCSDocApp_dar.log for the installation exceptions.
Errors occured while invoking Headless Composer.; Runtime execution failed with child process "$DOCUMENTUM_SHARED/java/1.7.0_72/jre/bin/java" exit code of 13; For more detailed information, see the error log: $DM_HOME/webcache/install/setupError.log

 

So what’s the issue? To understand how twisted/evil the IDS is, let’s first talk about the CS 7.3. When you install a Content Server 7.3, it will install the binaries, the JMS, the Headless Composer and a single Java which is: $DOCUMENTUM_SHARED/java64/JAVA_LINK. Well this is actually a symbolic link to the real Java version installed by a basic CS 7.3: $DOCUMENTUM_SHARED/java64/1.8.0_77. So for a Content Server 7.3, it’s simple, everything is using Java 8u77.

[dmadmin@content_server_01 install]$ echo $JAVA_HOME
$DOCUMENTUM_SHARED/java64/JAVA_LINK
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ ls -l $JAVA_HOME
lrwxrwxrwx. 1 dmadmin dmadmin 39 Oct  5 08:07 $DOCUMENTUM_SHARED/java64/JAVA_LINK -> $DOCUMENTUM_SHARED/java64/1.8.0_77
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ $JAVA_HOME/bin/java -version
java version "1.8.0_77"
Java(TM) SE Runtime Environment (build 1.8.0_77-b03)
Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode)
[dmadmin@content_server_01 install]$

 

Now why am I saying that the IDS is twisted? Well as you can see in the error message above, the path to the Java mentioned is “$DOCUMENTUM_SHARED/java/1.7.0_72″. Where is this coming from? One might think at first look that this is the java from a CS 7.2… And indeed it is the same version since a CS 7.2 was using Java 7u72 but it’s not even the same path… A CS 7.2 was using “$DOCUMENTUM_SHARED/java64/1.7.0_72″ (notice the “java64″ for 64 bits OS).

[dmadmin@content_server_01 install]$ $DOCUMENTUM_SHARED/java/1.7.0_72/bin/java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)

 

But it’s not all! If you take a look at the start script of the IDS 7.3 (below $IDS_HOME = $DOCUMENTUM_SHARED/wildfly9.0.1) you will see another Java!

[dmadmin@content_server_01 install]$ grep JAVA_HOME $IDS_HOME/server/startWEBCACHE.sh
JAVA_HOME="$DM_HOME/webcache/jre/linux"
export JAVA_HOME
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ $DM_HOME/webcache/jre/linux/bin/java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
[dmadmin@content_server_01 install]$

 

So when you install an IDS 7.3 on a CS 7.3 (that is already using Java 8u77), it will run using a Java 8u91 and it will also install a Java 7u72… Why would you make it easy when you can make it complicated! Since the IDS will only run using the Java 8u91, what’s the purpose of the Java 7u72 then? Well the only purpose I could find is precisely linked to this issue: to install DARs.

 

By default the Headless Composer – since installed with the CS 7.3 – will use the Java 8u77 ($DOCUMENTUM_SHARED/java64/JAVA_LINK) but the IDS isn’t able to install the DARs with Java 8. I don’t know where the Java version to be used by the IDS during the installation is defined but it might very well be hardcoded because the Installer is using the file /tmp/dctm_dmadmin/install_xxxxx/istempxxxxxyyyyyyyy/bundledLinux.jvm to know which Java to use and it’s always the Java 7u72 (the bundled one). You can try to update the file “$DM_HOME/webcache/install/install_info.ini” with a different “BUNDLED_JAVA_HOME” but it won’t change anything.

 

So then how can you control which Java should be used by the Headless Composer? That’s done in the java.ini file!

[dmadmin@content_server_01 install]$ grep -E "^java_library_path|^java_classpath" $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
java_library_path = $DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib/amd64/libjava.so
java_classpath = $DM_HOME/dctm-server.jar:$DOCUMENTUM_SHARED/dctm.jar:$DOCUMENTUM_SHARED/config:$DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib
[dmadmin@content_server_01 install]$

 

As you can see above (and I already said that above), the Headless Composer is using the Java that comes with the CS 7.3, so it is by default Java 8u77 ($DOCUMENTUM_SHARED/java64/JAVA_LINK). If you try to change the Java used in the java.ini file from Java 8u77 (CS 7.3) to Java 8u91 (IDS 7.3), it will still not work. What you need to do is changing the Java used to the value that the IDS expect and you can do it like that:

[dmadmin@content_server_01 install]$ grep -E "^java_library_path|^java_classpath" $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
java_library_path = $DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib/amd64/libjava.so
java_classpath = $DM_HOME/dctm-server.jar:$DOCUMENTUM_SHARED/dctm.jar:$DOCUMENTUM_SHARED/config:$DOCUMENTUM_SHARED/java64/JAVA_LINK/jre/lib
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ cp $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini_orig_before_IDS
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ export IDS_JAVA="$DOCUMENTUM_SHARED/java/1.7.0_72"
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ sed -i "s,$JAVA_HOME,$IDS_JAVA," $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
[dmadmin@content_server_01 install]$
[dmadmin@content_server_01 install]$ grep -E "^java_library_path|^java_classpath" $DM_HOME/install/composer/ComposerHeadless/plugins/com.emc.ide.external.dfc_1.0.0/dmbasic/linux/java.ini
java_library_path = $DOCUMENTUM_SHARED/java/1.7.0_72/jre/lib/amd64/libjava.so
java_classpath = $DM_HOME/dctm-server.jar:$DOCUMENTUM_SHARED/dctm.jar:$DOCUMENTUM_SHARED/config:$DOCUMENTUM_SHARED/java/1.7.0_72/jre/lib
[dmadmin@content_server_01 install]$

 

After doing that, you can try to execute the IDS Source Configurator again and this time, it will be able to install the IDS DARs into the target docbase. Don’t forget to restore the java.ini to its initial value afterwards…

 

 

Cet article Documentum – Unable to configure IDS 7.3 for a docbase est apparu en premier sur Blog dbi services.

Documentum xPlore: Several ways to start an Index Agent

$
0
0

In order to start index agents, you have several ways, depending on how you need to start them.

1. Use the documentum job dm_FTIndexAgentBoot. If you setup start_index_agents=T in the server.ini, the job will be called when the docbases are started.

2. Use the web interface:
Login to http://server:9200/IndexAgent/ with docbase credentials and select “Start in normal mode”

3. Login to DA and go to Indexing Management -> Index Agents and Index Servers
Right click on an index agent and select “Start Agent”

4. Use IAPI command to start it:

select index_name from dm_fulltext_index;
DOCBASE_ftindex_00
select object_name from dm_ftindex_agent_config;
server_9200_IndexAgent

apply,c,,FTINDEX_AGENT_ADMIN,NAME,S,DOCBASE_ftindex_00,AGENT_INSTANCE_NAME,S,server_9200_IndexAgent,ACTION,S,start
next,c,q0
dump,c,q0

5. Use Java:
java -cp $DM_HOME/lib/server-impl.jar:$DOCUMENTUM/dfc/dfc.jar com.documentum.server.impl.utils.IndexAgentCtrl -docbase_name <docbasename> -user_name <username> -action start

 

Cet article Documentum xPlore: Several ways to start an Index Agent est apparu en premier sur Blog dbi services.

Documentum xPlore: Tuning of JVM for high throughput and low CPU usage

$
0
0

Sometimes you have java processes or even jboss servers using a lot of CPU. In my example I had an xPlore dsearch server using like 98% of the cpu. When using jconsole and jvisualvm I figured out the garbage collector was using 50 to 60% of the cpu time.
This was because the server was indexing and accessing the internal DB very often. Hence a lot of objects were created, the JVM was not correctly sized, thus all objects went to the tenured(old) space resulting in filling up the heap. The garbage collector had to go through the whole heap and perform a lot of FUll GC. I went to a point where I had a Full GC every 5 seconds that lasted 4 seconds. So I had only 1 second every 5 seconds of “real” processing.

So if you have a process stuck in collecting garbage you can use the following parameters:
USER_MEM_ARGS=”-Xms8G -Xmx8G -XX:PermSize=64m -XX:NewSize=2g -XX:MaxNewSize=2g -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=95 -XX:+UseCMSInitiatingOccupancyOnly -XX:MaxTenuringThreshold=2 -XX:MaxPermSize=256m -Xss1024k -Xloggc:/pkgs/dmsp/opt/documentum/xPlore/jboss7.1.1/server/DctmServer_PrimaryDsearch/logs/PrimaryJVM.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution”

-Xms8G: Starting limit of the size of JVM
-Xmx8G: Max limit of heap usage
-XX:PermSize=64m: Permanent space size
-XX:MaxPermSize=256m:
-XX:NewSize=2g: Young Gen space size, here 1/4 of total
-XX:MaxNewSize=2: Maximum Young Gen space
-XX:+UseParNewGC: Parallele copying collector for Young generation, parallelizes the collection process with multiple threads, better perf with multiple processor architecture
-XX:+UseConcMarkSweepGC: Use concurrent mark-sweep collection for the old generation
-XX:+CMSParallelRemarkEnabled: Parallelize the remark phase, goes with CMS option, increases response time
-XX:+ParallelRefProcEnabled: Parallelize the process of weak referenced objects (cache)
-XX:+CMSClassUnloadingEnabled: Enables the class unloading capability for CMS
-XX:CMSInitiatingOccupancyFraction=95: Puts the limit after which the full GC will be trigered, higher value means less Full GC but longuer
-XX:+UseCMSInitiatingOccupancyOnly: Prevents the JVM tu use heuristics GC triggering rules, sets the trigger to use only the previous percentage as a threeshold for Full GC trigger.
-XX:MaxTenuringThreshold=2: Maximum value for tenuring threshold. The default value is 15
-Xss1024k: Thread stack size

These arguments will help you see the behaviour of the GC process:
-Xloggc:/path/to/log/JVM.log
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution

 

After tuning the JVM I went back to a normal behaviour:

jvm-all-green

 

Cet article Documentum xPlore: Tuning of JVM for high throughput and low CPU usage est apparu en premier sur Blog dbi services.

Documentum – DFC traces setup & investigation

$
0
0

When working with Documentum, you will most probably have to enable the DFC traces one day or another and then work with these traces to analyze them. The purpose of this blog is simply to show how the DFC traces can be enabled, which tools can be used to quickly process them and what are the limitations of such things.

Enabling the DFC traces can be done very easily by updating the dfc.properties file of the client. This client can be a DA, D2, JMS, Index Agent, aso… The change is applied directly (if enabled=true) and disabled by default (if commented or enable=false). If you have a dfc.properties that is inside a war file (for DA/D2 for example) and that you deployed your application as a war file (not exploded), then disabling the tracing might need a restart of your application. To avoid that, you can have a dfc.properties inside the war file that just point to another one outside of the war file and then enabling/disabling the traces from this second file will work properly. There are a lot of options to customize how the traces should be generated. A first example with only a few properties that you can use and reuse every time you need traces:

dfc.tracing.enable=true
dfc.tracing.verbose=true
dfc.tracing.max_stack_depth=0
dfc.tracing.mode=compact
dfc.tracing.dir=/tmp/dfc_tracing

 

Another example with more properties to really specify what you want to see:

dfc.tracing.enable=true
dfc.tracing.verbose=true
dfc.tracing.max_stack_depth=4
dfc.tracing.include_rpcs=true
dfc.tracing.mode=standard
dfc.tracing.include_session_id=true
dfc.tracing.user_name_filter[0]=dmadmin
dfc.tracing.user_name_filter[1]=myuser
dfc.tracing.thread_name_filter[0]=Thread-3
dfc.tracing.thread_name_filter[1]=Thread-25
dfc.tracing.timing_style=milliseconds_from_start
dfc.tracing.dir=/tmp/dfc_tracing
dfc.tracing.file_prefix=mydfc
dfc.tracing.max_backup_index=10
dfc.tracing.max_file_size=104857600
...

 

All these properties are quite easy to understand even without explanation but you can probably find more information and all the possible options in the official Documentum documentation. It’s not the main purpose of this blog so I’m just mentioning a few properties to get started. By default, the name of the generated files will be something like “dfctrace.timestamp.log”, you can change that by setting the “dfc.tracing.file_prefix” for example. Adding and customizing the properties will change the display format and style inside the files so if you want to have a way to analyze these DFC traces, it is better to use more or less always the same set of options. For the example below, OTX asked me to use these properties only:

dfc.tracing.enable=true
dfc.tracing.verbose=true
dfc.tracing.max_stack_depth=4
dfc.tracing.include_rpcs=true
dfc.tracing.mode=compact
dfc.tracing.include_session_id=true
dfc.tracing.dir=/tmp/dfc_tracing

 

When you have your DFC traces, you need a way to analyze them. They are pretty much readable but it will be complicated to get something out of it without spending a certain amount of time – unless you already know what you are looking for – simply because there are a lot of information inside… For that purpose, Ed Bueche developed more than 10 years ago some AWK scripts to parse the DFC traces files: traceD6.awk and trace_rpc_histD6.awk. You can find these scripts at the following locations (all EMC links… So might not be working at some point in the future):

As you can see above, it is not really maintained and the same scripts or a mix of several versions can be found at several locations so it can be a little bit confusing. All the old links are about the awk scripts but since 2013, there is now a python script too (also developed by Ed Bueche).

In this blog, I wanted to talk about the AWK scripts mainly. Earlier this month, I was working with OTX on some performance tuning tasks and for that, I gathered the DFC traces for several scenarios, in different log files, well separated, aso… Then, I provided them to OTX for the analysis. OTX came back to me a few minutes later saying that most of the traces were corrupted and asking me to regenerate them. I wasn’t quite OK with that simply because it takes time and because there were some testing in progress on this environment so gathering clean DFC traces for several scenarios would have forced the tests to be stopped, aso… (Ok ok you got me, I’m just lazy ;))

The content of the DFC traces looked correct to me and after a quick verification, I saw that OTX was using the AWK scripts (traceD6.awk and trace_rpc_histD6.awk) to analyze the logs but they were apparently getting an error. The files didn’t look corrupted to me so I mentioned to OTX that the issue might very well be with the AWK scripts they were using. They didn’t really listen to what I said and stayed focus on getting a new set of DFC traces. I already used these scripts but never really looked inside so it was the perfect reason to take some time for that:

[dmadmin@content_server_01 ~]$ cd /tmp/dfc_tracing/
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ ls -l trace* dfctrace.*.log
-rw-r-----. 1 dmadmin dmadmin 92661060 Nov 3 09:24 dfctrace.1510220481672.log
-rw-r-----. 1 dmadmin dmadmin 3240 Nov 4 14:10 traceD6.awk
-rw-r-----. 1 dmadmin dmadmin 7379 Nov 4 14:10 traceD6.py
-rw-r-----. 1 dmadmin dmadmin 5191 Nov 4 14:10 trace_rpc_histD6.awk
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ awk -f traceD6.awk < dfctrace.1510220481672.log > output_awk_1.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ wc -l output_awk_1.log
2 output_awk_1.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ awk -f trace_rpc_histD6.awk < dfctrace.1510220481672.log > output_awk_2.log
awk: trace_rpc_histD6.awk:203: (FILENAME=- FNR=428309) fatal: division by zero attempted
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ wc -l output_awk_2.log
4 output_awk_2.log
[dmadmin@content_server_01 dfc_tracing]$

 

As you can see above, the first script generated a log file that contains only 2 lines, so this is already suspicious even if there are no errors. The second script generated an error and its log file contains only 4 lines… The input DFC trace file has a size of 90Mb so it’s clear that there is something wrong and that’s why OTX said that the DFC traces were corrupted. The error message shows the line (203) as the origin of the issue as well as a “division by zero attempted” message. This obviously means that somewhere on this line, there is a division and that the divisor is equal to 0 or at least not set at all. Since I love all kind of UNIX scripting, I would rather fix the bug in the script than having to generate a new set of DFC traces (and the new set would still be impacted by the issue anyway…)! So checking inside the trace_rpc_histD6.awk file, the line 203 is the following one:

[dmadmin@content_server_01 dfc_tracing]$ grep -n -C1 "TIME SPENT" trace_rpc_histD6.awk
202-    printf ("DURATION (secs):\t%17.3f\n", ((curr_tms - st_tms)) );
203:    printf ("TIME SPENT EXECUTING RPCs (secs):%8.3f (which is %3.2f percent of total time)\n", total_rpc_time, 100*total_rpc_time/(curr_tms - st_tms));
204-    printf ("Threads :\t%25d\n", thread_cnt);
[dmadmin@content_server_01 dfc_tracing]$

 

The only division on this line is the total time taken to execute the RPCs divided by the duration of the log file (timestamp of last message – first message). So the value of “curr_tms – st_tms” is 0. Potentially, it could be that both variables have the exact same value but since the first and last messages on the DFC traces don’t have the same timestamp, this isn’t possible and therefore both variables are actually 0 or not set. To check where these variables are defined, how and in which function:

[dmadmin@content_server_01 dfc_tracing]$ grep -n -C15 -E "curr_tms|st_tms" trace_rpc_histD6.awk | grep -E "curr_tms|st_tms|^[0-9]*[:-][^[:space:]]"
144-/ .RPC:/ {
159:                    st_tms = $1;
162:            curr_tms = $1;
175-}
177-/obtained from pool/ {
--
187-}
188-/.INFO: Session/ {
193-}
197-END {
202:    printf ("DURATION (secs):\t%17.3f\n", ((curr_tms - st_tms)) );
203:    printf ("TIME SPENT EXECUTING RPCs (secs):%8.3f (which is %3.2f percent of total time)\n", total_rpc_time, 100*total_rpc_time/(curr_tms - st_tms));
[dmadmin@content_server_01 dfc_tracing]$

 

This shows that the only location where these two variables are set is inside the matching pattern “/ .RPC:/” (st_tms is set to $1 only on the first execution). So it means that this portion of code is never executed so in other words: this pattern is never found in the DFC trace file. Why is that? Well that’s pretty simple: the DFC traces file contains a lot of RPC calls but these lines never contain ” .RPC:”, there are always at least two dots (so something like that: ” ..RPC:” or ” …RPC:” or ” ….RPC:”). The reason why there are several dots is simply because the RPC are placed where they are called… In this case, OTX asked us to use “dfc.tracing.max_stack_depth=4″ so this is what I did and it is the reason why the AWK scripts cannot work by default because they need “dfc.tracing.max_stack_depth=0″, that’s written at the beginning of the scripts in the comment sections.

So a simple way to fix the AWK scripts is to remove the space at the beginning of the pattern for both the traceD6.awk and trace_rpc_histD6.awk scripts and after doing that, it will work for all max_stack_depth values:

[dmadmin@content_server_01 dfc_tracing]$ grep -n ".RPC:/" *.awk
traceD6.awk:145:/ .RPC:/ {
trace_rpc_histD6.awk:144:/ .RPC:/ {
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ sed -i 's,/ .RPC:/,/.RPC:/,' *.awk
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ grep -n ".RPC:/" *.awk
traceD6.awk:145:/.RPC:/ {
trace_rpc_histD6.awk:144:/.RPC:/ {
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ awk -f traceD6.awk < dfctrace.1510220481672.log > output_awk_1.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ wc -lc output_awk_1.log
 1961 163788 output_awk_1.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ awk -f trace_rpc_histD6.awk < dfctrace.1510220481672.log > output_awk_2.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ wc -l output_awk_2.log
 367 49050 output_awk_2.log
[dmadmin@content_server_01 dfc_tracing]$

 

That looks much much better… Basically, the first script list all RPCs with their thread, name and times while the second script creates a sorted list of queries that took the most time to execute as well as a list of calls and occurrences per types/names.

The AWK and Python scripts, even if they are globally working, might have some issues with commas, parenthesis and stuff like that (again it depends which dfc.tracing options you selected). This is why I mentioned above that there is actually both a AWK and Python version of these scripts. Sometimes, the AWK scripts will contain the right information, sometimes it is the Python version that will but in all cases, the later will run much faster. So if you want to work with these scripts, you will have to juggle a little bit:

[dmadmin@content_server_01 dfc_tracing]$ python traceD6.py dfctrace.1510220481672.log > output_py_1.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ wc -l output_py_1.log
 1959 194011 output_py_1.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ python traceD6.py dfctrace.1510220481672.log -profile > output_py_2.log
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ wc -l output_py_2.log
 342 65917 output_py_2.log
[dmadmin@content_server_01 dfc_tracing]$

 

As you can see, there are fewer lines in the python output files but that’s because some unnecessary headers have been removed in the python version so it’s actually normal. However there are much more characters so it shows that, in this case, the extracted DQL queries contain more characters but it does not mean that these characters are actually part of the DQL queries: you will see below that there are references to “, FOR_UPDATE=F, BATCH_HINT=50, BOF_DQL=T]],50,true,true)” => This is NOT part of the DQL but it is present on the output of the Python script while it is not for the AWK one:

[dmadmin@content_server_01 dfc_tracing]$ head -15 output_awk_1.log
analysis program version 2 based on DFC build 6.0.0.76
68354.130 & 0.005 & [http--0.0.0.0-9082-3] & EXEC_QUERY  select r_object_id from dm_sysobject where folder ('/Home') and object_name = 'Morgan Patou'
68354.135 & 0.000 & [http--0.0.0.0-9082-3] & multiNext
68354.136 & 0.005 & [http--0.0.0.0-9082-3] & SysObjFullFetch  0b0f12345004f0de
68354.165 & 0.002 & [http--0.0.0.0-9082-4] & EXEC_QUERY  select r_object_id from dm_user where user_name = 'Morgan Patou'
68354.167 & 0.000 & [http--0.0.0.0-9082-4] & multiNext
68354.167 & 0.002 & [http--0.0.0.0-9082-4] & IsCurrent
68354.170 & 0.003 & [http--0.0.0.0-9082-4] & EXEC_QUERY  SELECT COUNT(*) AS items FROM dm_group WHERE group_name = 'report_user' AND ANY i_all_users_names = 'Morgan Patou'
68354.173 & 0.001 & [http--0.0.0.0-9082-4] & multiNext
68354.175 & 0.003 & [http--0.0.0.0-9082-4] & EXEC_QUERY  select r_object_id from dm_sysobject where folder ('/myInsight') and object_name = 'myInsight.license'
68354.178 & 0.001 & [http--0.0.0.0-9082-4] & multiNext
68354.179 & 0.001 & [http--0.0.0.0-9082-4] & IsCurrent
68354.165 & 0.010 & [http--0.0.0.0-9082-3] & SysObjGetPermit
68354.175 & 0.006 & [http--0.0.0.0-9082-3] & SysObjGetXPermit
68354.181 & 0.006 & [http--0.0.0.0-9082-4] & MAKE_PULLER
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ head -15 output_py_1.log
68354.130 & 0.005 & [http--0.0.0.0-9082-3] & EXEC_QUERY & select r_object_id from dm_sysobject where folder ('/Home') and object_name = 'Morgan Patou', FOR_UPDATE=F, BATCH_HINT=50, BOF_DQL=T]],50,true,true)
68354.135 & 0.000 & [http--0.0.0.0-9082-3] & multiNext &
68354.136 & 0.005 & [http--0.0.0.0-9082-3] & SysObjFullFetch & 0b0f12345004f0de
68354.165 & 0.002 & [http--0.0.0.0-9082-4] & EXEC_QUERY & select r_object_id from dm_user where user_name = 'Morgan Patou', FOR_UPDATE=F, BATCH_HINT=50, BOF_DQL=T]],50,true,true)
68354.167 & 0.000 & [http--0.0.0.0-9082-4] & multiNext &
68354.167 & 0.002 & [http--0.0.0.0-9082-4] & IsCurrent & 110f123450001d07
68354.170 & 0.003 & [http--0.0.0.0-9082-4] & EXEC_QUERY & SELECT COUNT(*) AS items FROM dm_group WHERE group_name = 'report_user' AND ANY i_all_users_names = 'Morgan Patou', FOR_UPDATE=T, BATCH_HINT=50, BOF_DQL=T, FLUSH_BATCH=-1]],50,true,true)
68354.173 & 0.001 & [http--0.0.0.0-9082-4] & multiNext &
68354.175 & 0.003 & [http--0.0.0.0-9082-4] & EXEC_QUERY & select r_object_id from dm_sysobject where folder ('/myInsight') and object_name = 'myInsight.license', FOR_UPDATE=F, BATCH_HINT=50, BOF_DQL=T]],50,true,true)
68354.178 & 0.001 & [http--0.0.0.0-9082-4] & multiNext &
68354.179 & 0.001 & [http--0.0.0.0-9082-4] & IsCurrent & 090f123450023f63
68354.165 & 0.010 & [http--0.0.0.0-9082-3] & SysObjGetPermit & 0b0f12345004f0de
68354.175 & 0.006 & [http--0.0.0.0-9082-3] & SysObjGetXPermit & 0b0f12345004f0de
68354.181 & 0.006 & [http--0.0.0.0-9082-4] & MAKE_PULLER & null
68354.187 & 0.000 & [http--0.0.0.0-9082-4] & getBlock &
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$
[dmadmin@content_server_01 dfc_tracing]$ head -35 output_py_2.log

****** PROFILE OF rpc CALLS *****
     3.273           0.080              41      AUTHENTICATE_USER
     0.032           0.002              17      BEGIN_TRANS
     0.001           0.000              14      END_PUSH_V2
     0.202           0.012              17      END_TRANS
    21.898           0.071             310      EXEC_QUERY
     0.028           0.005               6      FETCH_CONTENT
     0.011           0.000              55      GET_ERRORS
     0.117           0.004              27      GET_LOGIN
     0.290           0.002             163      IsCurrent
     0.013           0.000              82      KILL_PULLER
     0.003           0.000              14      KILL_PUSHER
     0.991           0.012              82      MAKE_PULLER
     0.005           0.000              14      MAKE_PUSHER
     0.002           0.000               5      NEXT_ID_LIST
     0.083           0.002              38      NORPC
     0.015           0.005               3      RelationCopy
     0.446           0.032              14      SAVE
     0.274           0.014              20      SAVE_CONT_ATTRS
     0.140           0.010              14      START_PUSH
     0.134           0.045               3      SysObjCheckin
     0.048           0.016               3      SysObjCheckout
     2.199           0.009             240      SysObjFullFetch
     0.913           0.006             141      SysObjGetPermit
     0.764           0.005             141      SysObjGetXPermit
     0.642           0.046              14      SysObjSave
     0.033           0.000              82      getBlock
     1.454           0.004             399      multiNext

**** QUERY RESPONSE SORTED IN DESCENDING ORDER ****

10.317  select distinct wf.object_name as workflow_name, pr.object_name as process_name, i.name as Performer_Name, i.task_name as Task_Name, i.date_sent as Date_Task_Sent, i.actual_start_date as Date_Task_Acquired, wf.r_creator_name as Workflow_Initiator, cd.primary_group as "group", cd.subgroup as subgroup, cd.artifact_name as Artifact_Name, cd.object_name as document_name, cd.r_version_label as version_label, cd.title as Document_Title, cd.r_object_id as object_id from cd_common_ref_model(all) cd, dmi_package p, dmi_queue_item i, dm_workflow wf, dm_process pr
0.607   select r_object_id from dm_sysobject where folder ('/myInsight/Presentations/Standard Presentations/Graphical Reports') and object_name = 'FusionInterface.xsl', FOR_UPDATE=F, BATCH_HINT=50, BOF_DQL=T]],50,true,true)
0.505   select r_object_id from dm_sysobject where folder ('/myInsight/Presentations/Life Sciences') and object_name = 'Unique Templates.xsl', FOR_UPDATE=F, BATCH_HINT=50, BOF_DQL=T]],50,true,true)
[dmadmin@content_server_01 dfc_tracing]$

 

To conclude this blog on a more philosophical note: always question what other people ask you to do and think twice before doing the same thing over and over again. ;)

 

 

Cet article Documentum – DFC traces setup & investigation est apparu en premier sur Blog dbi services.

Documentum – DA 7.3 showing java.lang.NullPointerException on every actions

$
0
0

Last year, we started to upgrade some Documentum Administrator from 7.2 to 7.3 and directly after, we started to see some NullPointerException on the log files. We are using DA 7.3 on some recent WebLogic Servers versions (12.1.3, 12.2.1.2). We usually deploy DA as a WAR file (so not exploded) with just the dfc.properties, keystores and logs outside of it. This is the kind of errors we started to see as soon as it was upgraded to 7.3 in the startup log file (nohup log file in our case):

java.lang.NullPointerException
        at java.io.FileInputStream.<init>(FileInputStream.java:130)
        at java.io.FileInputStream.<init>(FileInputStream.java:93)
        at com.documentum.web.form.WebformTag.fetchExtnNativeVersion(WebformTag.java:282)
        at com.documentum.web.form.WebformTag.renderExtnJavaScript(WebformTag.java:268)
        at com.documentum.web.form.WebformTag.doStartTag(WebformTag.java:159)
        at jsp_servlet._custom._jsp.__loginex._jsp__tag3(__loginex.java:1687)
        at jsp_servlet._custom._jsp.__loginex._jspService(__loginex.java:272)
        at weblogic.servlet.jsp.JspBase.service(JspBase.java:35)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:286)
        at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:260)
        at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:137)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:350)
        at weblogic.servlet.internal.ServletStubImpl.onAddToMapException(ServletStubImpl.java:489)
        at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:376)
        ...

 

The stack on the line 7 and 8 changed, depending on the action that was being performed. For example an access to the login page would print the following:

        at jsp_servlet._custom._jsp.__loginex._jsp__tag3(__loginex.java:1687)
        at jsp_servlet._custom._jsp.__loginex._jspService(__loginex.java:272)

 

Then once logged in, you would see each component printing the same kind of stack, with the following lines 7 and 8:

        at jsp_servlet._webtop._main.__mainex._jsp__tag0(__mainex.java:286)
        at jsp_servlet._webtop._main.__mainex._jspService(__mainex.java:116)

 

        at jsp_servlet._webtop._classic.__classic._jsp__tag0(__classic.java:408)
        at jsp_servlet._webtop._classic.__classic._jspService(__classic.java:112)

 

        at jsp_servlet._webtop._titlebar.__titlebar._jsp__tag0(__titlebar.java:436)
        at jsp_servlet._webtop._titlebar.__titlebar._jspService(__titlebar.java:175)

 

        at jsp_servlet._webtop._messagebar.__messagebar._jsp__tag0(__messagebar.java:145)
        at jsp_servlet._webtop._messagebar.__messagebar._jspService(__messagebar.java:107)

 

aso…

We were working with OpenText on this issue. As mentioned in the stack trace, this is actually because DA is trying to fetch the “ExtnNativeVersion”. This is a property file located there: wdk/extension/client/EMC/ContentXfer/com.emc.wdk.native/1. Unfortunately, when DA 7.3 is trying to locate this file, it does not work but the file is really present… It does not work because the DA is deployed as a WAR file (an archive) and therefore the path to the file is wrong. I suspect this is something that Documentum changed recently, using the getRealPath(). To change the behavior of the getRealPath function, you have to set the property “Archived Real Path Enabled” to true so it returns the canonical path of the file…

So to remove these exceptions, you have two options:

I. At the domain level:

  1. Login to the WebLogic Administration Console using your weblogic account
  2. Navigate to the correct page: DOMAIN > Configuration > Web Applications
  3. Click on the ‘Lock & Edit’ button
  4. Check the ‘Archived Real Path Enabled’ checkbox ( = set it to true)
  5. Click on the ‘Save’ and then ‘Activate Changes’ buttons

This will add the configuration to the global config.xml file so it is enabled for the whole domain. As often, I would not recommend that but rather configuring this at the application level because you might have other applications that do NOT want this setting to be set to true… So that is why you have the option number two:

II. At the application level:

The high level steps to do that would be the following ones:

  1. Extract the weblogic.xml file from the application war file
  2. Add the ‘Archived Real Path Enabled’ property in it and set it to true
  3. Repackage the war file and redeploy it

This is pretty simple:

[weblogic@weblogic_server_01 ~]$ cd $APPS_HOME
[weblogic@weblogic_server_01 apps]$ jar -xvf da.war WEB-INF/weblogic.xml
 inflated: WEB-INF/weblogic.xml
[weblogic@weblogic_server_01 apps]$
[weblogic@weblogic_server_01 apps]$ vi WEB-INF/weblogic.xml
[weblogic@weblogic_server_01 apps]$
[weblogic@weblogic_server_01 apps]$ tail -6 WEB-INF/weblogic.xml

   <container-descriptor>
      <show-archived-real-path-enabled>true</show-archived-real-path-enabled>
   </container-descriptor>

</weblogic-web-app>
[weblogic@weblogic_server_01 apps]$
[weblogic@weblogic_server_01 apps]$ jar -uvf da.war WEB-INF/weblogic.xml
adding: WEB-INF/weblogic.xml(in = 989) (out= 398)(deflated 59%)
[weblogic@weblogic_server_01 apps]$

 

Then, you just need to update the deployment in the WebLogic Administration Console and that’s it, the exceptions should be gone now. As far as I’m aware of, these exceptions did not have any impact on the proper behavior of Documentum Administrator but it is still very ugly to have hundreds of them in the log file…

 

 

Cet article Documentum – DA 7.3 showing java.lang.NullPointerException on every actions est apparu en premier sur Blog dbi services.


Error starting D2 4.5 on Tomcat 8 No class found: JSAFE_SecureRandom

$
0
0

d2_logo_failed

When installing D2 and launching the tomcat server you can have an error on a missing lib: JSAFE_SecureRandom.

Here’s the trace you can have:

2018-01-17 17:32:19 [DEBUG] [localhost-startStop-1] - c.e.c.d.contents.D2FileCleaningTracker : Init D2FileCleaningTracker with /pkgs/dms-tomcat/D2_TOMCAT_HOME/temp/D2FileCleaningTracker_D2.ser
2018-01-17 17:32:20 [ERROR] [localhost-startStop-1] - c.emc.d2fs.dctm.servlets.D2HttpServlet : LoadOnStartup - java.lang.NoClassDefFoundError: com/rsa/jsafe/JSAFE_SecureRandom
2018-01-17 17:32:20 [ERROR] [localhost-startStop-1] - c.emc.d2fs.dctm.servlets.D2HttpServlet : {}
java.lang.NoClassDefFoundError: com/rsa/jsafe/JSAFE_SecureRandom
at com.documentum.fc.client.security.impl.InitializeKeystoreForDfc.execute(InitializeKeystoreForDfc.java:46) [dfc.jar:na]
at com.documentum.fc.client.security.internal.KeystoreMgr.initForDfcWithDefaultPolicy(KeystoreMgr.java:71) [dfc.jar:na]
at com.documentum.fc.client.security.impl.IdentityManager.initFromKeystore(IdentityManager.java:139) [dfc.jar:na]
at com.documentum.fc.client.security.impl.IdentityManager.<init>(IdentityManager.java:41) [dfc.jar:na]
at com.documentum.fc.impl.RuntimeContext.<init>(RuntimeContext.java:52) [dfc.jar:na]
at com.documentum.fc.impl.RuntimeContext.<clinit>(RuntimeContext.java:185) [dfc.jar:na]
at com.documentum.fc.client.DfClient.<clinit>(DfClient.java:772) [dfc.jar:na]
at com.emc.d2fs.dctm.servlets.init.SessionIterator.<init>(SessionIterator.java:77) [D2FS4DCTM-WEB-4.5.0.jar:na]
at com.emc.d2fs.dctm.servlets.init.LoadOnStartup.getSessions(LoadOnStartup.java:441) [D2FS4DCTM-WEB-4.5.0.jar:na]
at com.emc.d2fs.dctm.servlets.init.LoadOnStartup.processRequest(LoadOnStartup.java:164) [D2FS4DCTM-WEB-4.5.0.jar:na]
at com.emc.d2fs.dctm.servlets.D2HttpServlet.execute(D2HttpServlet.java:243) [D2FS4DCTM-API-4.5.0.jar:na]
at com.emc.d2fs.dctm.servlets.D2HttpServlet.doGetAndPost(D2HttpServlet.java:506) [D2FS4DCTM-API-4.5.0.jar:na]
at com.emc.d2fs.dctm.servlets.D2HttpServlet.doGet(D2HttpServlet.java:116) [D2FS4DCTM-API-4.5.0.jar:na]
at com.emc.d2fs.dctm.servlets.init.LoadOnStartup.init(LoadOnStartup.java:116) [D2FS4DCTM-WEB-4.5.0.jar:na]
at javax.servlet.GenericServlet.init(GenericServlet.java:158) [servlet-api.jar:3.0.FR]
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1284) [catalina.jar:7.0.53]
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1197) [catalina.jar:7.0.53]
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1087) [catalina.jar:7.0.53]
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5210) [catalina.jar:7.0.53]
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5493) [catalina.jar:7.0.53]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) [catalina.jar:7.0.53]
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) [catalina.jar:7.0.53]
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) [catalina.jar:7.0.53]
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:632) [catalina.jar:7.0.53]
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1073) [catalina.jar:7.0.53]
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1857) [catalina.jar:7.0.53]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_152]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_152]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_152]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_152]
Caused by: java.lang.ClassNotFoundException: com.rsa.jsafe.JSAFE_SecureRandom
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720) [catalina.jar:7.0.53]
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571) [catalina.jar:7.0.53]
... 31 common frames omitted

What’s the cause of this?

When you generate the D2 war file it requires some libraries like the dfs sdk. If you look into the logs you can see what has been added to the war file or at least what is missing. Well, for the sdk 7.x there are 2 libs missing, for generating the D2 war file for the version 4.5:

[copy] Warning: Could not find file /D24.5P29/emc-dfs-sdk-7.3/lib/java/dfc/certjFIPS.jar to copy.
[copy] Warning: Could not find file /D24.5P29/emc-dfs-sdk-7.3/lib/java/dfc/jsafeFIPS.jar to copy.

Resolution

To resolve the issue, copy these 2 libraries from the 6.7SP2 dfs sdk and paste them into the lib folder of D2.

 

Cet article Error starting D2 4.5 on Tomcat 8 No class found: JSAFE_SecureRandom est apparu en premier sur Blog dbi services.

Documentum – Unable to restart a JMS, failed deployment of bundle.jar

$
0
0

While working on a very big Documentum project with several other teams, some people were complaining that the JMS wouldn’t start anymore on one of the DEV environments. It is kind of rare to face an issue with the JMS itself (JBoss works pretty well usually…) so I was interested in checking this. This was a Documentum 7.2 environment but I’m sure it would apply to older versions as well as newer versions (7.x, 16.4, …). This was the content of the JMS console output:

[dmadmin@content_server_01 ~]$ cat $JMS_HOME/server/nohup-JMS.out
...
2018-06-12 07:15:54,765 UTC INFO  [org.jboss.modules] JBoss Modules version 1.1.1.GA
2018-06-12 07:15:54,968 UTC INFO  [org.jboss.msc] JBoss MSC version 1.0.2.GA
2018-06-12 07:15:55,019 UTC INFO  [org.jboss.as] JBAS015899: JBoss AS 7.1.1.Final "Brontes" starting
2018-06-12 07:15:56,415 UTC INFO  [org.jboss.as.server] JBAS015888: Creating http management service using socket-binding (management-http)
2018-06-12 07:15:56,417 UTC INFO  [org.xnio] XNIO Version 3.0.3.GA
2018-06-12 07:15:56,428 UTC INFO  [org.xnio.nio] XNIO NIO Implementation Version 3.0.3.GA
2018-06-12 07:15:56,437 UTC INFO  [org.jboss.remoting] JBoss Remoting version 3.2.3.GA
2018-06-12 07:15:56,448 UTC INFO  [org.jboss.as.logging] JBAS011502: Removing bootstrap log handlers
2018-06-12 07:15:56,478 UTC INFO  [org.jboss.as.configadmin] (ServerService Thread Pool -- 27) JBAS016200: Activating ConfigAdmin Subsystem
2018-06-12 07:15:56,486 UTC INFO  [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 32) JBAS010280: Activating Infinispan subsystem.
2018-06-12 07:15:56,510 UTC INFO  [org.jboss.as.osgi] (ServerService Thread Pool -- 40) JBAS011940: Activating OSGi Subsystem
2018-06-12 07:15:56,518 UTC INFO  [org.jboss.as.naming] (ServerService Thread Pool -- 39) JBAS011800: Activating Naming Subsystem
2018-06-12 07:15:56,527 UTC INFO  [org.jboss.as.security] (ServerService Thread Pool -- 45) JBAS013101: Activating Security Subsystem
2018-06-12 07:15:56,533 UTC INFO  [org.jboss.as.security] (MSC service thread 1-9) JBAS013100: Current PicketBox version=4.0.7.Final
2018-06-12 07:15:56,535 UTC INFO  [org.jboss.as.connector] (MSC service thread 1-4) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final)
2018-06-12 07:15:56,548 UTC INFO  [org.jboss.as.webservices] (ServerService Thread Pool -- 49) JBAS015537: Activating WebServices Extension
2018-06-12 07:15:56,585 UTC INFO  [org.jboss.as.naming] (MSC service thread 1-1) JBAS011802: Starting Naming Service
2018-06-12 07:15:56,594 UTC INFO  [org.jboss.as.mail.extension] (MSC service thread 1-12) JBAS015400: Bound mail session 
2018-06-12 07:15:56,688 UTC INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-8) JBoss Web Services - Stack CXF Server 4.0.2.GA
2018-06-12 07:15:56,727 UTC INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-10) Starting Coyote HTTP/1.1 on http--0.0.0.0-9080
2018-06-12 07:15:56,821 UTC INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-13) live server is starting with configuration HornetQ Configuration (clustered=false,backup=false,sharedStore=true,journalDirectory=$JMS_HOME/server/DctmServer_MethodServer/data/messagingjournal,bindingsDirectory=$JMS_HOME/server/DctmServer_MethodServer/data/messagingbindings,largeMessagesDirectory=$JMS_HOME/server/DctmServer_MethodServer/data/messaginglargemessages,pagingDirectory=$JMS_HOME/server/DctmServer_MethodServer/data/messagingpaging)
2018-06-12 07:15:56,827 UTC INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-13) Waiting to obtain live lock
2018-06-12 07:15:56,852 UTC INFO  [org.hornetq.core.persistence.impl.journal.JournalStorageManager] (MSC service thread 1-13) Using AIO Journal
2018-06-12 07:15:56,923 UTC INFO  [org.hornetq.core.server.impl.AIOFileLockNodeManager] (MSC service thread 1-13) Waiting to obtain live lock
2018-06-12 07:15:56,924 UTC INFO  [org.hornetq.core.server.impl.AIOFileLockNodeManager] (MSC service thread 1-13) Live Server Obtained live lock
2018-06-12 07:15:56,981 UTC INFO  [org.jboss.as.remoting] (MSC service thread 1-5) JBAS017100: Listening on 0.0.0.0/0.0.0.0:9092
2018-06-12 07:15:56,982 UTC INFO  [org.jboss.as.remoting] (MSC service thread 1-14) JBAS017100: Listening on /127.0.0.1:9084
2018-06-12 07:15:56,996 UTC INFO  [org.jboss.as.server.deployment.scanner] (MSC service thread 1-10) JBAS015012: Started FileSystemDeploymentService for directory $JMS_HOME/server/DctmServer_MethodServer/deployments
2018-06-12 07:15:57,019 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment bundle.jar
2018-06-12 07:15:57,020 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment bundle.jar
2018-06-12 07:15:57,021 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment bundle.jar
2018-06-12 07:15:57,023 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment bundle.jar
2018-06-12 07:15:57,024 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment bundle.jar
2018-06-12 07:15:57,025 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015014: Re-attempting failed deployment bundle.jar
2018-06-12 07:15:57,026 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found ServerApps.ear in deployment directory. To trigger deployment create a file called ServerApps.ear.dodeploy
2018-06-12 07:15:57,027 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found XhiveConnector.ear in deployment directory. To trigger deployment create a file called XhiveConnector.ear.dodeploy
2018-06-12 07:15:57,028 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found bpm.ear in deployment directory. To trigger deployment create a file called bpm.ear.dodeploy
2018-06-12 07:15:57,029 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found acs.ear in deployment directory. To trigger deployment create a file called acs.ear.dodeploy
2018-06-12 07:15:57,090 UTC INFO  [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http-0.0.0.0-0.0.0.0-9082
2018-06-12 07:15:57,235 UTC INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-13) Started Netty Acceptor version 3.2.5.Final-a96d88c 0.0.0.0:9090 for CORE protocol
2018-06-12 07:15:57,237 UTC INFO  [org.hornetq.core.remoting.impl.netty.NettyAcceptor] (MSC service thread 1-13) Started Netty Acceptor version 3.2.5.Final-a96d88c 0.0.0.0:9091 for CORE protocol
2018-06-12 07:15:57,239 UTC INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-13) Server is now live
2018-06-12 07:15:57,239 UTC INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-13) HornetQ Server version 2.2.13.Final (HQ_2_2_13_FINAL_AS7, 122) [b774a781-a4da-11e6-a1e8-005056082847]) started
2018-06-12 07:15:57,256 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-14) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
2018-06-12 07:15:57,257 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-14) JBAS011601: Bound messaging object to jndi name java:/RemoteConnectionFactory
2018-06-12 07:15:57,258 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-4) JBAS011601: Bound messaging object to jndi name java:/ConnectionFactory
2018-06-12 07:15:57,261 UTC INFO  [org.hornetq.core.server.impl.HornetQServerImpl] (MSC service thread 1-9) trying to deploy queue jms.queue.touchRpcQueue
2018-06-12 07:15:57,267 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-9) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/queue/touchRpcQueue
2018-06-12 07:15:57,268 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-9) JBAS011601: Bound messaging object to jndi name java:/queue/touchRpcQueue
2018-06-12 07:15:57,269 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-3) JBAS011601: Bound messaging object to jndi name java:/TouchRpcQueueConnectionFactory
2018-06-12 07:15:57,270 UTC INFO  [org.jboss.as.messaging] (MSC service thread 1-3) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/TouchRpcQueueConnectionFactory
2018-06-12 07:15:57,301 UTC INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-8) JBAS010406: Registered connection factory java:/JmsXA
2018-06-12 07:15:57,311 UTC INFO  [org.hornetq.ra.HornetQResourceAdapter] (MSC service thread 1-8) HornetQ resource adaptor started
2018-06-12 07:15:57,312 UTC INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-8) IJ020002: Deployed: file://RaActivatorhornetq-ra
2018-06-12 07:15:57,316 UTC INFO  [org.jboss.as.deployment.connector] (MSC service thread 1-4) JBAS010401: Bound JCA ConnectionFactory 
2018-06-12 07:15:57,343 UTC ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) Operation ("add") failed - address: ([("deployment" => "bundle.jar")]) - failure description: "JBAS014803: Duplicate resource [(\"deployment\" => \"bundle.jar\")]"
2018-06-12 07:15:57,348 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
2018-06-12 07:15:57,349 UTC INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9085
2018-06-12 07:15:57,350 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
2018-06-12 07:15:57,350 UTC INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 2885ms - Started 148 of 226 services (78 services are passive or on-demand)
2018-06-12 07:15:57,351 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
2018-06-12 07:15:57,353 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
2018-06-12 07:15:57,354 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS014654: Composite operation was rolled back
2018-06-12 07:15:57,355 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "JBAS014803: Duplicate resource [(\"deployment\" => \"bundle.jar\")]"}}
2018-06-12 07:15:57,357 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) undefined
2018-06-12 07:15:57,358 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) undefined
2018-06-12 07:15:57,359 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) undefined
2018-06-12 07:15:57,359 UTC ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) undefined

 

This was linked to deployments so I tried as a first step to force a redeploy of all Documentum applications. It can be done as shown below and in those cases, it is better to stop the JMS before otherwise it will try to redeploy the applications on the fly, which might work but you aren’t sure they will start again on next startup… So here are the steps:

[dmadmin@content_server_01 ~]$ cd $JMS_HOME/server/DctmServer_MethodServer/deployments
[dmadmin@content_server_01 deployments]$ 
[dmadmin@content_server_01 deployments]$ find . -maxdepth 1 -name "*.failed"
./acs.ear.failed
./ServerApps.ear.failed
./error.war.failed
./bpm.ear.failed
[dmadmin@content_server_01 deployments]$ 
[dmadmin@content_server_01 deployments]$ 
[dmadmin@content_server_01 deployments]$ for i in `find . -maxdepth 1 -name "*.failed"`; do name=`echo ${i} | sed 's,.failed,.dodeploy,'`; mv ${i} ${name}; done
[dmadmin@content_server_01 deployments]$

 

Then you can just start again the JMS:

[dmadmin@content_server_01 deployments]$ $JMS_HOME/server/startJMS.sh
Starting the JMS...
The JMS process has been started.
[dmadmin@content_server_01 deployments]$

 

Unfortunately in this case, the JMS logs were similar and the Documentum applications were still in failed. So looking closer at these logs, it seemed to be related to a bundle.jar file:

[dmadmin@content_server_01 deployments]$ find . -name bundle.jar
./felix-cache/bundle3/version0.0/bundle.jar
./felix-cache/bundle5/version0.0/bundle.jar
./felix-cache/bundle1/version0.0/bundle.jar
./felix-cache/bundle4/version0.0/bundle.jar
./felix-cache/bundle6/version0.0/bundle.jar
./felix-cache/bundle2/version0.0/bundle.jar
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ ls felix-cache/*
felix-cache/bundle0:
bundle.id

felix-cache/bundle1:
bundle.id  bundle.lastmodified  bundle.location  bundle.startlevel  bundle.state  version0.0

felix-cache/bundle2:
bundle.id  bundle.lastmodified  bundle.location  bundle.startlevel  bundle.state  version0.0

felix-cache/bundle3:
bundle.id  bundle.lastmodified  bundle.location  bundle.startlevel  bundle.state  version0.0

felix-cache/bundle4:
bundle.id  bundle.lastmodified  bundle.location  bundle.startlevel  bundle.state  version0.0

felix-cache/bundle5:
bundle.id  bundle.lastmodified  bundle.location  bundle.startlevel  bundle.state  version0.0

felix-cache/bundle6:
bundle.id  bundle.lastmodified  bundle.location  bundle.startlevel  bundle.state  version0.0
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ for i in `ls felix-cache/`; do echo "felix-cache/${i}:"; cat felix-cache/${i}/bundle.location; echo; echo; done
felix-cache/bundle0:
cat: felix-cache/bundle0/bundle.location: No such file or directory


felix-cache/bundle1:
file:$JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/HttpService.jar

felix-cache/bundle2:
file:$JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/HttpServiceImpl.jar

felix-cache/bundle3:
file:$JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/Common.jar

felix-cache/bundle4:
file:$JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/Web.jar

felix-cache/bundle5:
file:$JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/Jmx.jar

felix-cache/bundle6:
file:$JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/org.apache.felix.bundlerepository-1.2.1.jar

[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ diff felix-cache/bundle1/version0.0/bundle.jar $JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/HttpService.jar
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ diff felix-cache/bundle3/version0.0/bundle.jar $JMS_HOME/server/DctmServer_MethodServer/deployments/acs.ear/lib/Common.jar
[dmadmin@content_server_01 deployments]$

 

This felix-cache is normally created by the ACS when you start it and it will normally be placed in the folder from where you start the JMS. In this case, it was under the deployments folder, probably because someone started the JMS using the startMethodServer.sh script directly and he didn’t use our custom start script (startJMS.sh as you can see above and below) which actually takes care of that and switch to the correct folder before (and with the proper nohup, aso…). Because it was created under the deployments folder, the JMS was trying to deploy it as any other applications and so it failed. As you can see above, the file “bundle.jar” (in the different folders) is actually a copy of some of the ACS library files – the ones mentioned in the bundle.location – that has been put to the felix-cache by the ACS.

As you know, with a newly installed JMS for Documentum, there is no felix-cache folder under the deployments. What you can find here are the ServerApps, ACS or BPM for example but that’s pretty much it. Therefore, to solve this issue, simply remove the felix-cache folder, force a new deployment of all Documentum applications, restart it again properly and it should be good then:

[dmadmin@content_server_01 deployments]$ $JMS_HOME/server/stopMethodServer.sh; sleep 5; ps -ef | grep MethodServer
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ rm -rf felix-cache/
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ find . -maxdepth 1 -name "*.failed"
./acs.ear.failed
./ServerApps.ear.failed
./error.war.failed
./bpm.ear.failed
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ for i in `find . -maxdepth 1 -name "*.failed"`; do name=`echo ${i} | sed 's,.failed,.dodeploy,'`; mv ${i} ${name}; done
[dmadmin@content_server_01 deployments]$
[dmadmin@content_server_01 deployments]$ $JMS_HOME/server/startJMS.sh
Starting the JMS...
The JMS process has been started.
[dmadmin@content_server_01 deployments]$

 

Then checking if the issue is gone and if all the applications are now properly deployed:

[dmadmin@content_server_01 deployments]$ grep -E " deployment | Deployed " $JMS_HOME/server/nohup-JMS.out
2018-06-12 07:30:15,142 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found ServerApps.ear in deployment directory. To trigger deployment create a file called ServerApps.ear.dodeploy
2018-06-12 07:30:15,144 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found XhiveConnector.ear in deployment directory. To trigger deployment create a file called XhiveConnector.ear.dodeploy
2018-06-12 07:30:15,145 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found bpm.ear in deployment directory. To trigger deployment create a file called bpm.ear.dodeploy
2018-06-12 07:30:15,146 UTC INFO  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) JBAS015003: Found acs.ear in deployment directory. To trigger deployment create a file called acs.ear.dodeploy
2018-06-12 07:30:15,503 UTC INFO  [org.jboss.as.connector.services.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-1) IJ020002: Deployed: file://RaActivatorhornetq-ra
2018-06-12 07:30:15,535 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "bpm.ear"
2018-06-12 07:30:15,535 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-13) JBAS015876: Starting deployment of "ServerApps.ear"
2018-06-12 07:30:15,535 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "error.war"
2018-06-12 07:30:15,535 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015876: Starting deployment of "acs.ear"
2018-06-12 07:30:17,824 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "documentum-bocs-ws.war"
2018-06-12 07:30:17,825 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-15) JBAS015876: Starting deployment of "bocs.war"
2018-06-12 07:30:18,093 UTC INFO  [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/ACS]] (MSC service thread 1-16) Initializing CORS filter as per the deployment descriptor
2018-06-12 07:30:18,608 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015876: Starting deployment of "DmMethods.war"
2018-06-12 07:30:18,608 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-9) JBAS015876: Starting deployment of "DmMail.war"
2018-06-12 07:30:18,904 UTC INFO  [org.jboss.as.server.deployment] (MSC service thread 1-11) JBAS015876: Starting deployment of "bpm.war"
2018-06-12 07:30:32,017 UTC INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "bpm.ear"
2018-06-12 07:30:32,019 UTC INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "error.war"
2018-06-12 07:30:32,020 UTC INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "acs.ear"
2018-06-12 07:30:32,021 UTC INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "ServerApps.ear"
[dmadmin@content_server_01 deployments]$

 

So takes care when you start the JMS, if you do not have any custom script (it’s pretty much mandatory for the JMS!) or if you do not change the working directory before executing the startMethodServer.sh script, you might have some surprises.

 

Edit: After writing this blog, I searched the OTX website for something related to this and found that there is a KB (KB7795388) about this but I think this blog still makes sense because it provides more information and some explanation. That’s a bad habit of mine, I usually try fixing things myself before checking the OTX website because I don’t like it and the less I’m using it, the better.

 

 

Cet article Documentum – Unable to restart a JMS, failed deployment of bundle.jar est apparu en premier sur Blog dbi services.

Documentum – Silent Install – Things to know, binaries & JMS installation

$
0
0

Documentum introduced some time ago already the silent installations for its software. The way to use this changed a little bit but it seems they finally found their way. This blog will be the first of a series to present how to work with the silent installations on Documentum because it is true that it is not really well documented and most probably not much used at the moment.

We are using this where possible for our customers and it is true that it is really helpful to avoid human errors and install components more quickly. Be aware that this isn’t perfect! There are some parameters with typos, some parameters that are really not self-explanatory, so you will need some time to understand everything but, in the end, it is still helpful.

Using the silent installation is a first step but you will still need a lot of manual interventions to execute these as well as actually making your environment working. I mean it only replaces the GUI installers so everything you were doing around that is still needed (preparation of files/folders/environment, custom start/stop scripts, service setup, Java Method Server (JMS) configuration, Security Baselines, SSL setup, aso…). That’s why we also developed internally scripts or playbooks (Ansible for example) to perform everything around AND use the Documentum silent installations. In this blog and more generally in this series, I will only talk about the silent installations coming from Documentum.

Let’s start with the basis:

  1. Things you need to know
  2. Documentum Content Server installation (binaries & JMS)

 

1. Things you need to know

  • Each and every component installation needs its own properties file that is used by the installer to know what to install and how to do it, that’s all you need to do.
  • As I mentioned above, there are some typos in a few parameters coming from the properties files like “CONGINUE” instead of “CONTINUE”. These aren’t errors in my blogs, the parameters are really like that. All the properties files I’m showing here have been tested and validated in a lot of environments, including PROD ones in High Availability.
  • To know more about the silent installation, you can check the installation documentation. There isn’t much to read about it but still some potentially interesting information.
  • The Documentum documentation does NOT contain any description of the parameters you can/should use, that’s why I will try in each blogs to describe them as much as possible.
  • You can potentially do several things at once using a single silent properties file, the only restriction for that is that it needs to use the same installer. Therefore, you could install a docbroker/connection broker, a docbase/repository and configure/enable a licence using a single properties file but you wouldn’t be able to do the silent installation of the binaries as well because it needs another installer. That’s definitively not what I’m doing because I find it messy, I really prefer to separate things, so I know I’m using only the parameters that I need for a specific component and nothing else.
  • There are examples provided when you install Documentum. You can look at the folder “$DM_HOME/install/silent/templates” and you will see some properties file. In these files, you will usually find most of the parameters that you can use but from what I remember, there are a few missing. Be aware that some files are for Windows and some are for Linux, it’s not always the same because some parameters are specific to a certain OS:
    • linux_ files are for Linux obviously
    • win_ files are for Windows obviously
    • cfs_ files are for a CFS/Remote Content Server installation (to provide High Availability to your docbases/repositories)
  • If you look at the folder “$DM_HOME/install/silent/silenttool”, you will see that there is a utility to generate silent files based on your current installation. You need to provide a silent installation file for a Content Server and it will generate for you a CFS/Remote CS silent installation file with most of the parameters that you need. Do not 100% rely on this file, there might still be some parameters missing but present ones should be the correct ones. I will write a blog on the CFS/Remote CS as well, to provide an example.
  • You can generate silent properties file by running the Documentum installers with the following command: “<installer_name>.<sh/bin> -r <path>/<file_name>.properties”. This will write the parameters you selected/enabled/configured into the <file_name>.properties file so you can re-use it later.
  • To install an additional JMS, you can use the jmsConfig.sh script or jmsStandaloneSetup.bin for an IJMS (Independent JMS – Documentum 16.4 only). It won’t be in the blogs because I’m only showing the default one created with the binaries.
  • The following components/features can be installed using the silent mode (it is possible that I’m missing some, these are the ones I know):
    • CS binaries + JMS
    • JMS/IJMS
    • Docbroker/connection broker
    • Licences
    • Docbase/repository (CS + CFS/RCS + DMS + RKM)
    • D2
    • Thumbnail

 

2. Documentum Content Server installation (binaries & JMS)

Before starting, you need to have the Documentum environment variables defined ($DOCUMENTUM, $DM_HOME, $DOCUMENTUM_SHARED), that doesn’t change. Once that is done, you need to extract the installer package (below I used the package for a CS 7.3 on Linux with an Oracle DB):

[dmadmin@content_server_01 ~]$ cd /tmp/dctm_install/
[dmadmin@content_server_01 dctm_install]$ tar -xvf Content_Server_7.3_linux64_oracle.tar
[dmadmin@content_server_01 dctm_install]$
[dmadmin@content_server_01 dctm_install]$ chmod 750 serverSetup.bin
[dmadmin@content_server_01 dctm_install]$ rm Content_Server_7.3_linux64_oracle.tar

 

Then prepare the properties file:

[dmadmin@content_server_01 dctm_install]$ vi CS_Installation.properties
[dmadmin@content_server_01 dctm_install]$ cat CS_Installation.properties
### Silent installation response file for CS binary
INSTALLER_UI=silent
KEEP_TEMP_FILE=true

### Installation parameters
APPSERVER.SERVER_HTTP_PORT=9080
APPSERVER.SECURE.PASSWORD=adm1nP4ssw0rdJMS

### Common parameters
COMMON.DO_NOT_RUN_DM_ROOT_TASK=true

[dmadmin@content_server_01 dctm_install]$

 

A short description of these properties:

  • INSTALLER_UI: The mode to use for the installation, here it is obviously silent
  • KEEP_TEMP_FILE: Whether or not you want to keep the temporary files created by the installer. These files are generated under the /tmp folder. I usually keep them because I want to be able to check them if something went wrong
  • APPSERVER.SERVER_HTTP_PORT: The port to be used by the JMS that will be installed
  • APPSERVER.SECURE.PASSWORD: The password of the “admin” account of the JMS. Yes, you need to put all passwords in clear text in the silent installation properties files so add it just before starting the installation and remove them right after
  • COMMON.DO_NOT_RUN_DM_ROOT_TASK: Whether or not you want to run the dm_root_task in the silent installation. I usually set it to true, so it is NOT executed because the Installation Owner I’m using do not have root accesses for security reasons
  • On Windows, you would need to provide the Installation Owner’s password as well and the path you want to install Documentum on ($DOCUMENTUM). On linux, the first one isn’t needed and the second one needs to be in the environment before starting.
  • You could also potentially add more properties in this file: SERVER.LOCKBOX_FILE_NAMEx and SERVER.LOCKBOX_PASSPHRASE.PASSWORDx (where x is a number starting with 1 and incrementing in case you have several lockboxes). These parameters would be used for existing lockbox files that you would want to load. Honestly, these parameters are useless. You will anyway need to provide the lockbox information during the docbase/repository creation and you will need to specify if you want a new lockbox, an existing lockbox or no lockbox at all so specifying it here is kind of useless…

 

Once the properties file is ready, you can install the Documentum binaries and the JMS in silent using the following command:

[dmadmin@content_server_01 dctm_install]$ ./serverSetup.bin -f CS_Installation.properties

 

This conclude the first blog of this series about Documentum silent installations. Stay tuned for more soon.

 

Cet article Documentum – Silent Install – Things to know, binaries & JMS installation est apparu en premier sur Blog dbi services.

Documentum – Silent Install – Docbroker & Licences

$
0
0

In a previous blog, I quickly went through the different things to know about the silent installations as well as how to install the CS binaries. Once the CS binaries are installed, you can install/configure a few more components. On this second blog, I will continue with:

  • Documentum docbroker/connection broker installation
  • Configuration of a Documentum licence

 

1. Documentum docbroker/connection broker installation

As mentioned in the previous blog, the examples provided by Documentum contain almost all possible parameters but for this section, only a very few of them are required. The properties file for a docbroker/connection broker installation is as follow:

[dmadmin@content_server_01 ~]$ vi /tmp/dctm_install/CS_Docbroker.properties
[dmadmin@content_server_01 ~]$ cat /tmp/dctm_install/CS_Docbroker.properties
### Silent installation response file for a Docbroker
INSTALLER_UI=silent
KEEP_TEMP_FILE=true

### Action to be executed
SERVER.CONFIGURATOR.LICENSING=false
SERVER.CONFIGURATOR.REPOSITORY=false
SERVER.CONFIGURATOR.BROKER=true

### Docbroker parameters
SERVER.DOCBROKER_ACTION=CREATE
SERVER.DOCBROKER_PORT=1489
SERVER.DOCBROKER_NAME=Docbroker
SERVER.PROJECTED_DOCBROKER_HOST=content_server_01.dbi-services.com
SERVER.PROJECTED_DOCBROKER_PORT=1489
SERVER.DOCBROKER_CONNECT_MODE=dual

### Common parameters
START_METHOD_SERVER=false
MORE_DOCBASE=false
SERVER.CONGINUE.MORECOMPONENT=false

[dmadmin@content_server_01 ~]$

 

A short description of these properties:

  • INSTALLER_UI: The mode to use for the installation, here it is obviously silent
  • KEEP_TEMP_FILE: Whether or not you want to keep the temporary files created by the installer. These files are generated under the /tmp folder. I usually keep them because I want to be able to check them if something went wrong
  • SERVER.CONFIGURATOR.LICENSING: Whether or not you want to configure a licence using this properties file. Here since we just want a docbroker/connection broker, it is obviously false
  • SERVER.CONFIGURATOR.REPOSITORY: Whether or not you want to configure a docbase/repository. Same here, it will be false
  • SERVER.CONFIGURATOR.BROKER: Whether or not you want to configure a docbroker/connection broker. That’s the purpose of this properties file so it will be true
  • SERVER.DOCBROKER_ACTION: The action to be executed, it can be either CREATE, UPGRADE or DELETE. You can upgrade a Documentum environment in silent even if the source doesn’t support the silent installation/upgrade as long as the target version (CS 7.3, CS 16.4, …) does
  • SERVER.DOCBROKER_PORT: The port the docbroker/connection broker will listen to (always the native port)
  • SERVER.DOCBROKER_NAME: The name of the docbroker/connection broker to create/upgrade/delete
  • SERVER.PROJECTED_DOCBROKER_HOST: The hostname to use for the dfc.properties projection for this docbroker/connection broker
  • SERVER.PROJECTED_DOCBROKER_PORT: The port to use for the dfc.properties projection related to this docbroker/connection broker. It should obviously be the same as “SERVER.DOCBROKER_PORT”, don’t ask me why there are two different parameters for that…
  • SERVER.DOCBROKER_CONNECT_MODE: The connection mode to use for the docbroker/connection broker, it can be either native, dual or secure. If it is dual or secure, you have 2 choices:
    • Use the default “Anonymous” mode, which is actually not really secure
    • Use a real “SSL Certificate” mode, which requires some more parameters to be configured (and you need to have the keystore and truststore already available):
      • SERVER.USE_CERTIFICATES: Whether or not to use SSL Certificate for the docbroker/connection broker
      • SERVER.DOCBROKER_KEYSTORE_FILE_NAME: The name of the p12 file that contains the keystore
      • SERVER.DOCBROKER_KEYSTORE_PASSWORD_FILE_NAME: The name of the password file that contains the password of the keystore
      • SERVER.DOCBROKER_CIPHER_LIST: Colon separated list of ciphers to be enabled (E.g.: EDH-RSA-AES256-GCM-SHA384:EDH-RSA-AES256-SHA)
      • SERVER.DFC_SSL_TRUSTSTORE: Full path and name of the truststore to be used that contains the SSL Certificate needed to trust the targets
      • SERVER.DFC_SSL_TRUSTSTORE_PASSWORD: The password of the truststore in clear text
      • SERVER.DFC_SSL_USE_EXISTING_TRUSTSTORE: Whether or not to use the Java truststore or the 2 above parameters instead
  • START_METHOD_SERVER: Whether or not you want the JMS to be re-started again once the docbroker/connection broker has been created. Since we usually create the docbroker/connection broker just before creating the docbases/repositories and since the docbases/repositories will anyway stop the JMS, we can leave it stopped there
  • MORE_DOCBASE: Never change this value, it should remain as false as far as I know
  • SERVER.CONGINUE.MORECOMPONENT: Whether or not you want to configure some additional components. Same as above, I would always let it as false… I know that the name of this parameter is strange but that’s the name that is coming from the templates… But if you look a little bit on the internet, you might be able to find “SERVER.CONTINUE.MORE.COMPONENT” as well… So which one is “correct”, which one isn’t is still a mystery for me. I’m using the first one but since I always set it to false, that doesn’t have any impact for me and I never saw any errors coming from the log files or anything.

 

Once the properties file is ready, you can install the docbroker/connection broker using the following command:

[dmadmin@content_server_01 ~]$ $DM_HOME/install/dm_launch_server_config_program.sh -f /tmp/dctm_install/CS_Docbroker.properties

 

That’s it, after a few seconds, the prompt will be returned and the docbroker/connection broker will be installed with the provided parameters.

 

2. Configuration of a Documentum licence

Once you have a docbroker/connection broker installed, you can configure/enable a certain amount of licences (actually you could have done it before). For this example, I will only enable the TCS but you can do it for all others too. The properties file for a licence configuration is as follow:

[dmadmin@content_server_01 ~]$ vi /tmp/dctm_install/CS_Licence.properties
[dmadmin@content_server_01 ~]$ cat /tmp/dctm_install/CS_Licence.properties
### Silent installation response file for a Licence
INSTALLER_UI=silent
KEEP_TEMP_FILE=true

### Action to be executed
SERVER.CONFIGURATOR.LICENSING=true
SERVER.CONFIGURATOR.REPOSITORY=false
SERVER.CONFIGURATOR.BROKER=false

### Licensing parameters
SERVER.TCS_LICENSE=DummyLicenceForTCS

### Common parameters
START_METHOD_SERVER=false
MORE_DOCBASE=false
SERVER.CONGINUE.MORECOMPONENT=false

[dmadmin@content_server_01 ~]$

 

A short description of these properties – compared to the above ones:

  • SERVER.CONFIGURATOR.LICENSING & SERVER.CONFIGURATOR.BROKER: This time, we will obviously set the broker to false and the licensing to true so we do not re-install another docbroker/connection broker
  • Licences:
    • SERVER.TCS_LICENSE: Licence string to enable the Trusted Content Services on this CS
    • SERVER.XHIVE_LICENSE: Licence string to enable the XML Store Feature
    • SERVER.AS_LICENSE: Licence string to enable the Archive Service
    • SERVER.CSSL_LICENSE: Licence string to enable the Content Storage Service Licence
    • aso… Some of these licences require more parameters to be added (XHIVE: “XHIVE.PAGE.SIZE”, “SERVER.ENABLE_XHIVE”, “SERVER.XHIVE_HOST”, aso…)

 

It might make sense to enable some licences during the installation of a specific docbase/repository so then that would be up to you to think about this. In the above example, I only enabled the TCS so it is available to all docbases/repositories that will be installed on this Content Server. Therefore, it makes sense to do separately, before the installation of the docbases/repositories.

You now know how to install and configure a docbroker/connection broker as well as how to enable licences using the silent installation provided by Documentum

 

Cet article Documentum – Silent Install – Docbroker & Licences est apparu en premier sur Blog dbi services.

Documentum – Silent Install – Docbases/Repositories

$
0
0

In previous blogs, we installed in silent the Documentum binaries as well as a docbroker (+licence(s) if needed). In this one, we will see how to install docbases/repositories and by that, I mean either a Global Registry (GR) repository or a normal repository.

As you all know, you will need a repository to be a GR and I would always recommend to setup a GR that isn’t used by the end-users (no real documents). That’s why I will split this blog into two: the installation of a GR and then, the installation of a normal repository that will be used by end-users. So, let’s get to it.

 

1. Documentum Global Registry repository installation

The properties file for a GR installation is as follow (it’s a big one):

[dmadmin@content_server_01 ~]$ vi /tmp/dctm_install/CS_Docbase_GR.properties
[dmadmin@content_server_01 ~]$ cat /tmp/dctm_install/CS_Docbase_GR.properties
### Silent installation response file for a Docbase (GR)
INSTALLER_UI=silent
KEEP_TEMP_FILE=true

### Action to be executed
SERVER.CONFIGURATOR.LICENSING=false
SERVER.CONFIGURATOR.REPOSITORY=true
SERVER.CONFIGURATOR.BROKER=false

### Docbase parameters
SERVER.DOCBASE_ACTION=CREATE

common.use.existing.aek.lockbox=common.create.new
common.aek.passphrase.password=a3kP4ssw0rd
common.aek.key.name=CSaek
common.aek.algorithm=AES_256_CBC
SERVER.ENABLE_LOCKBOX=true
SERVER.LOCKBOX_FILE_NAME=lockbox.lb
SERVER.LOCKBOX_PASSPHRASE.PASSWORD=l0ckb0xP4ssw0rd

SERVER.DOCUMENTUM_DATA_FOR_SAN_NAS=false
SERVER.DOCUMENTUM_DATA=
SERVER.DOCUMENTUM_SHARE=
SERVER.FQDN=content_server_01.dbi-services.com

SERVER.DOCBASE_NAME=gr_docbase
SERVER.DOCBASE_ID=1010101
SERVER.DOCBASE_DESCRIPTION=Global Registry repository for silent install blog

SERVER.PROJECTED_DOCBROKER_HOST=content_server_01.dbi-services.com
SERVER.PROJECTED_DOCBROKER_PORT=1489
SERVER.TEST_DOCBROKER=true
SERVER.CONNECT_MODE=dual

SERVER.USE_EXISTING_DATABASE_ACCOUNT=true
SERVER.INDEXSPACE_NAME=DM_GR_DOCBASE_INDEX
SERVER.DATABASE_CONNECTION=DEMODBNAME
SERVER.DATABASE_ADMIN_NAME=gr_docbase
SERVER.SECURE.DATABASE_ADMIN_PASSWORD=gr_d0cb4seP4ssw0rdDB
SERVER.DOCBASE_OWNER_NAME=gr_docbase
SERVER.SECURE.DOCBASE_OWNER_PASSWORD=gr_d0cb4seP4ssw0rdDB
SERVER.DOCBASE_SERVICE_NAME=gr_docbase

SERVER.GLOBAL_REGISTRY_SPECIFY_OPTION=USE_THIS_REPOSITORY
SERVER.BOF_REGISTRY_USER_LOGIN_NAME=dm_bof_registry
SERVER.SECURE.BOF_REGISTRY_USER_PASSWORD=dm_b0f_reg1s7ryP4ssw0rd

### Common parameters
SERVER.ENABLE_XHIVE=false
SERVER.CONFIGURATOR.DISTRIBUTED_ENV=false
SERVER.ENABLE_RKM=false
START_METHOD_SERVER=false
MORE_DOCBASE=false
SERVER.CONGINUE.MORECOMPONENT=false

[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ sed -i "s,SERVER.DOCUMENTUM_DATA=.*,SERVER.DOCUMENTUM_DATA=$DOCUMENTUM/data," /tmp/dctm_install/CS_Docbase_GR.properties
[dmadmin@content_server_01 ~]$ sed -i "s,SERVER.DOCUMENTUM_SHARE=.*,SERVER.DOCUMENTUM_SHARE=$DOCUMENTUM/share," /tmp/dctm_install/CS_Docbase_GR.properties
[dmadmin@content_server_01 ~]$

 

In the above commands, I didn’t put the SERVER.DOCUMENTUM_DATA and SERVER.DOCUMENTUM_SHARE into the file directly but I used sed commands to update the file later because I didn’t want to direct you to use a certain path for your installation like /app or /opt or /var or whatever… This choice is yours, so I just used sub-folders of $DOCUMENTUM and used this environment variable to set both parameters so you can choose which path you want for the Data and Share folder (the above is the default but you can set what you want).

A short description of these properties:

  • INSTALLER_UI: The mode to use for the installation, here it is obviously silent
  • KEEP_TEMP_FILE: Whether or not you want to keep the temporary files created by the installer. These files are generated under the /tmp folder. I usually keep them because I want to be able to check them if something went wrong
  • SERVER.CONFIGURATOR.LICENSING: Whether or not you want to configure a licence using this properties file. Here since we just want a docbase/repository, it is obviously false
  • SERVER.CONFIGURATOR.REPOSITORY: Whether or not you want to configure a docbase/repository. That’s the purpose of this properties file so it will be true
  • SERVER.CONFIGURATOR.BROKER: Whether or not you want to configure a docbroker/connection broker. Same as the licence, it will be false
  • SERVER.DOCBASE_ACTION: The action to be executed, it can be either CREATE, UPGRADE or DELETE. You can upgrade a Documentum environment in silent even if the source doesn’t support the silent installation/upgrade as long as the target version (CS 7.3, CS 16.4, …) does
  • common.use.existing.aek.lockbox: Whether to use an existing aek or create a new one. Possible values are “common.create.new” or “common.use.existing”. In this case, it is the first docbase/repository created so we are creating a new one. In case of migration/upgrade, you might want to use an existing one (after upgrading it) …
  • common.aek.passphrase.password: The password to be used for the AEK
  • common.aek.key.name: The name of the AEK key to be used. This is usually something like “CSaek”
  • common.aek.algorithm: The algorithm to be used for the AEK key. I would recommend the strongest one, if possible: “AES_256_CBC”
  • SERVER.ENABLE_LOCKBOX: Whether or not you want to use a Lockbox to protect the AEK key. If set to true, a lockbox will be created and the AEK key will be stored in it
  • SERVER.LOCKBOX_FILE_NAME: The name of the Lockbox to be used. This is usually something like “lockbox.lb”
  • SERVER.LOCKBOX_PASSPHRASE.PASSWORD: The password to be used for the Lockbox
  • SERVER.DOCUMENTUM_DATA_FOR_SAN_NAS: Whether or not the “SERVER.DOCUMENTUM_DATA” and “SERVER.DOCUMENTUM_SHARE” are using a SAN or NAS path
  • SERVER.DOCUMENTUM_DATA: The path to be used to store the Documentum documents, accessible from all Content Servers which will host this docbase/repository
  • SERVER.DOCUMENTUM_SHARE: The path to be used for the share folder
  • SERVER.FQDN: The Fully Qualified Domain Name of the current host the docbase/repository is being installed on
  • SERVER.DOCBASE_NAME: The name of the docbase/repository to be created (dm_docbase_config.object_name)
  • SERVER.DOCBASE_ID: The ID of the docbase/repository to be created
  • SERVER.DOCBASE_DESCRIPTION: The description of the docbase/repository to be created (dm_docbase_config.title)
  • SERVER.PROJECTED_DOCBROKER_HOST: The hostname to be use for the [DOCBROKER_PROJECTION_TARGET] on the server.ini file, meaning the docbroker/connection broker the docbase/repository should project to, by default
  • SERVER.PROJECTED_DOCBROKER_PORT: The port to be use for the [DOCBROKER_PROJECTION_TARGET] on the server.ini file, meaning the docbroker/connection broker the docbase/repository should project to, by default
  • SERVER.TEST_DOCBROKER: Whether or not you want to test the docbroker/connection broker connection during the installation. I would recommand to always set this to true to be sure the docbase/repository is installed properly… If a docbroker/connection broker isn’t available, the installation will not be complete (DARs installation for example) but you will not see any error, unless you manually check the installation log…
  • SERVER.CONNECT_MODE: The connection mode of the docbase/repository to be used (dm_server_config.secure_connect_mode), it can be either native, dual or secure. If it is dual or secure, you have 2 choices:
    • Use the default “Anonymous” mode, which is actually not really secure
    • Use a real “SSL Certificate” mode, which requires some more parameters to be configured:
      • SERVER.USE_CERTIFICATES: Whether or not to use SSL Certificate for the docbase/repository
      • SERVER.KEYSTORE_FILE_NAME: The name of the p12 file that contains the keystore
      • SERVER.KEYSTORE_PASSWORD_FILE_NAME: The name of the password file that contains the password of the keystore
      • SERVER.TRUST_STORE_FILE_NAME: The name of the p7b file that contains the SSL Certificate needed to trust the targets (from a docbase point of view)
      • SERVER.CIPHER_LIST: Colon separated list of ciphers to be enabled (E.g.: EDH-RSA-AES256-GCM-SHA384:EDH-RSA-AES256-SHA)
      • SERVER.DFC_SSL_TRUSTSTORE: Full path and name of the truststore to be used that contains the SSL Certificate needed to trust the targets (from a DFC/client point of view)
      • SERVER.DFC_SSL_TRUSTSTORE_PASSWORD: The password of the truststore in clear text
      • SERVER.DFC_SSL_USE_EXISTING_TRUSTSTORE: Whether or not to use the Java truststore or the 2 above parameters instead
  • SERVER.USE_EXISTING_DATABASE_ACCOUNT: Whether or not you want to use an existing DB Account or create a new one. I don’t like when an installer is requesting you full access to a DB so I’m usually preparing the DB User upfront with only the bare minimal set of permissions required and then using this account for the Application (Documentum docbase/repository in this case)
  • SERVER.INDEXSPACE_NAME: The name of the tablespace to be used to store the indexes (to be set if using existing DB User)
  • SERVER.DATABASE_CONNECTION: The name of the Database to connect to. This needs to be available on the tnsnames.ora if using Oracle, aso…
  • SERVER.DATABASE_ADMIN_NAME: The name of the Database admin account to be used. There is no reason to put anything else than the same as the schema owner’s account here… If you configured the correct permissions, you don’t need a DB admin account at all
  • SERVER.SECURE.DATABASE_ADMIN_PASSWORD: The password of the above-mentioned account
  • SERVER.DOCBASE_OWNER_NAME: The name of the schema owner’s account to be used for runtime
  • SERVER.SECURE.DOCBASE_OWNER_PASSWORD: The password of the schema owner’s account
  • SERVER.DOCBASE_SERVICE_NAME: The name of the service to be used. To be set only when using Oracle…
  • SERVER.GLOBAL_REGISTRY_SPECIFY_OPTION: If this docbase/repository should be a Global Registry, then set this to “USE_THIS_REPOSITORY”, otherwise do not set the parameter. If the GR is on a remote host, you need to set this to “SPECIFY_DIFFERENT_REPOSITORY” and then use a few additional parameters to specify the name of the GR repo and the host it is currently running on
  • SERVER.BOF_REGISTRY_USER_LOGIN_NAME: The name of the BOF Registry account to be created. This is usually something like “dm_bof_registry”
  • SERVER.SECURE.BOF_REGISTRY_USER_PASSWORD=The password to be used for the BOF Registry account
  • SERVER.ENABLE_XHIVE: Whether or not you want to enable the XML Store Feature. As I mentioned in the blog with the licences, this is one of the thing you might want to enable the licence during the docbase/repository configuration. If you want to enable the XHIVE, you will need to specify a few additional parameters like the XDB user/password, host and port, aso…
  • SERVER.CONFIGURATOR.DISTRIBUTED_ENV: Whether or not you want to enable/configure the DMS. If you set this to true, you will need to add a few more parameters like the DMS Action to be performed, the webserver port, host, password, aso…
  • SERVER.ENABLE_RKM: Whether or not you want to enable/configure the RKM. If you set this to true, you will need to add a few more parameters like the host/port on which the keys will be stored, the certificates and password, aso…
  • START_METHOD_SERVER: Whether or not you want the JMS to be re-started again once the docbase/repository has been created. Since we usually create at least 2 docbases/repositories, we can leave it stopped there
  • MORE_DOCBASE: Never change this value, it should remain as false as far as I know
  • SERVER.CONGINUE.MORECOMPONENT: Whether or not you want to configure some additional components. Same as above, I would always let it as false… I know that the name of this parameter is strange but that’s the name that is coming from the templates… But if you look a little bit on the internet, you might be able to find “SERVER.CONTINUE.MORE.COMPONENT” instead… So which one is working, which one isn’t is still a mystery for me. I use the first one but since I always set it to false, that doesn’t have any impact for me and I never saw any errors coming from the log files.

 

Once the properties file is ready, you can install the Global Registry repository using the following command:

[dmadmin@content_server_01 ~]$ $DM_HOME/install/dm_launch_server_config_program.sh -f /tmp/dctm_install/CS_Docbase_GR.properties

 

Contrary to previous installations, this will take some time (around 20 minutes) because it needs to install the docbase/repository, then there are DARs that need to be installed, aso… Unfortunately, there is no feedback on the progress, so you just need to wait and in case something goes wrong, you won’t even notice since there are no errors shown… Therefore, check the logs to be sure!

 

2. Other repository installation

Once you have a Global Registry repository installed, you can install the repository that will be used by the end-users (which isn’t a GR then). The properties file for an additional repository is as follow:

[dmadmin@content_server_01 ~]$ vi /tmp/dctm_install/CS_Docbase_Other.properties
[dmadmin@content_server_01 ~]$ cat /tmp/dctm_install/CS_Docbase_Other.properties
### Silent installation response file for a Docbase
INSTALLER_UI=silent
KEEP_TEMP_FILE=true

### Action to be executed
SERVER.CONFIGURATOR.LICENSING=false
SERVER.CONFIGURATOR.REPOSITORY=true
SERVER.CONFIGURATOR.BROKER=false

### Docbase parameters
SERVER.DOCBASE_ACTION=CREATE

common.use.existing.aek.lockbox=common.use.existing
common.aek.passphrase.password=a3kP4ssw0rd
common.aek.key.name=CSaek
common.aek.algorithm=AES_256_CBC
SERVER.ENABLE_LOCKBOX=true
SERVER.LOCKBOX_FILE_NAME=lockbox.lb
SERVER.LOCKBOX_PASSPHRASE.PASSWORD=l0ckb0xP4ssw0rd

SERVER.DOCUMENTUM_DATA_FOR_SAN_NAS=false
SERVER.DOCUMENTUM_DATA=
SERVER.DOCUMENTUM_SHARE=
SERVER.FQDN=content_server_01.dbi-services.com

SERVER.DOCBASE_NAME=Docbase1
SERVER.DOCBASE_ID=1010102
SERVER.DOCBASE_DESCRIPTION=Docbase1 repository for silent install blog

SERVER.PROJECTED_DOCBROKER_HOST=content_server_01.dbi-services.com
SERVER.PROJECTED_DOCBROKER_PORT=1489
SERVER.TEST_DOCBROKER=true
SERVER.CONNECT_MODE=dual

SERVER.USE_EXISTING_DATABASE_ACCOUNT=true
SERVER.INDEXSPACE_NAME=DM_DOCBASE1_INDEX
SERVER.DATABASE_CONNECTION=DEMODBNAME
SERVER.DATABASE_ADMIN_NAME=docbase1
SERVER.SECURE.DATABASE_ADMIN_PASSWORD=d0cb4se1P4ssw0rdDB
SERVER.DOCBASE_OWNER_NAME=docbase1
SERVER.SECURE.DOCBASE_OWNER_PASSWORD=d0cb4se1P4ssw0rdDB
SERVER.DOCBASE_SERVICE_NAME=docbase1

### Common parameters
SERVER.ENABLE_XHIVE=false
SERVER.CONFIGURATOR.DISTRIBUTED_ENV=false
SERVER.ENABLE_RKM=false
START_METHOD_SERVER=true
MORE_DOCBASE=false
SERVER.CONGINUE.MORECOMPONENT=false

[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$
[dmadmin@content_server_01 ~]$ sed -i "s,SERVER.DOCUMENTUM_DATA=.*,SERVER.DOCUMENTUM_DATA=$DOCUMENTUM/data," /tmp/dctm_install/CS_Docbase_Other.properties
[dmadmin@content_server_01 ~]$ sed -i "s,SERVER.DOCUMENTUM_SHARE=.*,SERVER.DOCUMENTUM_SHARE=$DOCUMENTUM/share," /tmp/dctm_install/CS_Docbase_Other.properties
[dmadmin@content_server_01 ~]$

 

I won’t list all these parameters again but just the ones that changed, except the docbase/repository name/id/description and DB accounts/tablespaces since these are pretty obvious:

  • Updated parameter’s value:
    • common.use.existing.aek.lockbox: As mentioned above, since the AEK key is now created (as part of the GR installation), this now need to be set to “common.use.existing” instead
  • Removed parameter (all these will be taken from the dfc.properties that has been updated as part of the GR installation):
    • SERVER.GLOBAL_REGISTRY_SPECIFY_OPTION
    • SERVER.BOF_REGISTRY_USER_LOGIN_NAME
    • SERVER.SECURE.BOF_REGISTRY_USER_PASSWORD

 

Once the properties file is ready, you can install the additional repository in the same way:

[dmadmin@content_server_01 ~]$ $DM_HOME/install/dm_launch_server_config_program.sh -f /tmp/dctm_install/CS_Docbase_Other.properties

 

You now know how to install and configure a Global Registry repository as well as any other docbase/repository on a “Primary” Content Server using the silent installation provided by Documentum. In a later blog, I will talk about specificities related to a “Remote” Content Server for a High Availability environment.

 

Cet article Documentum – Silent Install – Docbases/Repositories est apparu en premier sur Blog dbi services.

Viewing all 173 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>