authMN SM.accessPolicy out of synch with CN and replicaMN
Lauren noticed some replica packages from urn:node:GOA on urn:node:KNB today that did not have public read allowed on their data files. The CN also does not have public read for these data objects. I suspect that the EML <access> was updated at some point after the package was initially saved and the CN harvested it from the GOA node. The updates to the SystemMetadata.accessPolicy are correctly reflected on the GOA (which is the authoritative MN for these objects).
This is somewhat of a "known" issue in that SM.accessPolicy can only be updated on the CN using the CN.setAccessPolicy() method which then calls back the all MNs that hold replicas (or originals) and informs them of the change. A long time ago we realized that this robs the authMN of their primary authority on the object but have not been able to re-architect DataONE to support authMN-control.
In the interim, which could be forever, we should make sure Metacat calls CN.setAccessPolicy() whenever it changes on the authMN. Typically this will happen when parsing an updated EML file that contains additional (or fewer) access control rules but there is also a Metacat servlet API call to set access blocks (action=setaccess, I believe).
While we can put in place code to deal with future changes to the SM.accessPolicy, we also want a mechanism for fixing the ones that we have today. There are a couple options for that: manually with a bash script and a few curl commands, or an upgrade routine included for the next release of Metacat that is run automatically during upgrade, or after Metacat has been completely [re]configured as a Member Node. (There are client certificate configuration issues to think about if using an upgrade routine).
#2 Updated by ben leinfelder almost 8 years ago
Original on GOA: https://goa.nceas.ucsb.edu/#view/df35d.455.4
Replica on KNB: https://knb.ecoinformatics.org/m/#view/df35d.455.4
one of the data files on each server:
Correct on authMN: http://goa.nceas.ucsb.edu/goa/d1/mn/v1/meta/df35d.21.2
Incorrect on CN: https://cn.dataone.org/cn/v1/meta/df35d.21.2
Incorrect of targetMN: http://knb.ecoinformatics.org/knb/d1/mn/v1/meta/df35d.21.2