What happens when smart guy does not sit back

Previously I posted about performance challenge related to a lot of fetches from docbase, there I have described what makes SysObjFullFetch RPC command extremely slow – a set of useless SQL queries:

-- determine object type by r_object_id
SELECT dm_dbalias_B.I_TYPE
  FROM DMI_OBJECT_TYPE dm_dbalias_B
 WHERE dm_dbalias_B.R_OBJECT_ID = :dmb_handle
 
-- retrieve data from database
  SELECT *
    FROM TYPE_RV dm_dbalias_B, TYPE_SV dm_dbalias_C
   WHERE (    dm_dbalias_C.R_OBJECT_ID = :dmb_handle
          AND dm_dbalias_C.R_OBJECT_ID = dm_dbalias_B.R_OBJECT_ID)
ORDER BY dm_dbalias_B.R_OBJECT_ID, dm_dbalias_B.I_POSITION
 
-- get identifier of object's ACL (totally useless)
SELECT dm_dbalias_B.R_OBJECT_ID
  FROM DM_ACL_S dm_dbalias_B
 WHERE (dm_dbalias_B.OWNER_NAME = :p00 
    AND dm_dbalias_B.OBJECT_NAME = :p01)
 
-- retrieve object's ACL
SELECT *
    FROM DM_ACL_RV dm_dbalias_B, DM_ACL_SV dm_dbalias_C
   WHERE (    dm_dbalias_C.R_OBJECT_ID = :dmb_handle
          AND dm_dbalias_C.R_OBJECT_ID = dm_dbalias_B.R_OBJECT_ID)
ORDER BY dm_dbalias_B.R_OBJECT_ID, dm_dbalias_B.I_POSITION
 
-- check whether ACL is actual or not (totally useless)
SELECT dm_dbalias_B.R_OBJECT_ID
  FROM DM_ACL_S dm_dbalias_B
 WHERE (    dm_dbalias_B.R_OBJECT_ID = :dmb_objectp
        AND dm_dbalias_B.I_VSTAMP = :dmb_versionp)

Let me clarify why I do think so.
This query:

-- get identifier of object's ACL (totally useless)
SELECT dm_dbalias_B.R_OBJECT_ID
  FROM DM_ACL_S dm_dbalias_B
 WHERE (dm_dbalias_B.OWNER_NAME = :p00 
    AND dm_dbalias_B.OBJECT_NAME = :p01)

is completely useless because technically we do not need r_object_id of ACL to retrieve ACL from database in follow-up query:

-- retrieve object's ACL
SELECT *
    FROM DM_ACL_RV dm_dbalias_B, DM_ACL_SV dm_dbalias_C
   WHERE (    dm_dbalias_C.R_OBJECT_ID = :dmb_handle
          AND dm_dbalias_C.R_OBJECT_ID = dm_dbalias_B.R_OBJECT_ID)
ORDER BY dm_dbalias_B.R_OBJECT_ID, dm_dbalias_B.I_POSITION

so, we can replace two queries by the single one:

SELECT *
    FROM DM_ACL_RV dm_dbalias_B, DM_ACL_SV dm_dbalias_C
   WHERE (    dm_dbalias_C.OWNER_NAME = :p00 
          AND dm_dbalias_C.OBJECT_NAME = :p01
          AND dm_dbalias_C.R_OBJECT_ID = dm_dbalias_B.R_OBJECT_ID)
ORDER BY dm_dbalias_B.R_OBJECT_ID, dm_dbalias_B.I_POSITION

Moreover, in some set of cases we do not need to check ACLs at all, these cases are:

  • current user is a superuser or a member of dm_browse_all (dm_read_all, etc) group, or current user is a sysobject’s owner
  • sysobject has r_is_public=T or world_permit>=2 and MACL is turned off:

It had taken about 3 months to force EMC to change something in Content Server to improve performance (frankly speaking EMC employees had no idea about r_is_public and world_permit attributes), and finally we have following notice in patch notes:

Below is a comparison of single thread performance (amount of fetches per 10 seconds) between old and new implementation for case when sysobject has r_is_public=T (I believe that orange graph’s laydown is related to GC settings):

Developer “PostgreSQL” edition fun

18 months ago EMC released an extremely buggy version of Documentum Content Server intended for development purposes, some of ECN members perfectly described the situation with it:

and EMC’s reaction for such critics was extremely eloquent (I do believe that nobody likes critics, but ignoring real problems perfectly describes your respectfulness to the customers):

Three weeks ago new version of Developer Edition got appeared on EMC’s ftp server:

What we should expect from new version?

  • Networking issues are still not resolved (it is weird because I already mentioned a good receipt for that – it also must be accomplished by following shell scenario:
    cd /etc/udev/rules.d
    rm -f 70-persistent-net.rules
    rm -f 75-persistent-net-generator.rules
    echo "# " > 75-persistent-net-generator.rules

    ):

  • EMC decided to use weird lockbox feature, quote from readme file:

    4. Run dm_crypto_create and dm_crypto_boot utilities to enable Lockbox.
    ———————————————————————-
    4.1 Execute dm_crypto_create utility as below:
    dm_crypto_create -lockbox lockbox.lb -lockboxpassphrase Password@123 -keyname
    aek.key -passphrase Password@123 -check

    4.2 Run dm_crypto_boot utility as below:
    dm_crypto_boot -all
    Provide the key store passphrase as “Password@123” when prompted.

    , i.e. now you will need to run

    dm_crypto_boot -all -lockbox lockbox.lb \
     -lockboxpassphrase Password@123 -passphrase Password@123

    upon every reboot

  • xPlore still does not work:
  • there is still no reliable installer
  • and the real gem is EMC disclosed their regression tests (check /opt/Suites directory) – now you can get a real progress on developer edition πŸ™‚

Q & A. X

Q:

Hi,
I am trying to write a standalone DF/D2 program. I create a DFC session and then make it in D2 context by D2Session.initTBO. I think perform normal DFC set, save operation on a sysobject. When I try to apply a D2 configuration like D2AuditConfig.apply I get the below error How to correct this??

ERROR 1 – D2 lockbox file or D2Method.passphrase property within it could not be found.
Exception in thread β€œmain” DfException:: THREAD: main; MSG: Impossible to decrypt the method server response; ERRORCODE: ff; NEXT: null
at com.emc.d2.api.methods.D2Method.start(D2Method.java:417)

A:

You have two options:

  • put and setup all Lockbox stuff onto client side
  • Take advantage of reflection:
    Field ticketField = D2Session.class.getField("s_ticket");
    ticketField.setAccessible(true);
    Map tickets = (Map) ticketField.get(null);
    tickets.put("docbase_name", "dmadmin_password");
    

Q:

Also, cant it disable Lockbox altogether in 7.2+D24.5 environment?

A:

Download latest (or m.b. previous to latest or so) service pack for D2 4.2, extract com.emc.common.java.crypto.AESCrypto class from C6-Common-4.2.0.jar, insert it into C6-Common-4.5.0.jar.

Have you read latest ESA?

On August 6 EMC announced 6 security fixes for Content Server:

being the authorresearcher of the first five (I believe EMC found the last one in another blog) vulnerabilities I will shed light on them very soon, however I can’t understand what CS versions was remediated – it seems that version numbers were received from /dev/random: