Bug #7927
Archive operation not permitted for V1 readonly MNs
100%
Description
While attempting to archive content for SEAD in the production environment using a CN certificate to authenticate:
d1_common.types.exceptions.ServiceFailure: name: ServiceFailure
errorCode: 500
detailCode: 4972
description: Couldn't determine the authoritative member node storage version for the pid seadva-HsuLeslie029090a9-11b8-4fc1-bf76-bb5a8153363f
The request is authenticated OK, but fails when the CN attempts to determine the version of the Storage API provided by the MN.
In this case, the MN is a Tier 1 node using the V1 API.
The problem lies in: /edu/ucsb/nceas/metacat/dataone/CNodeService.java at around line 601.
If the returned version is null then the node does not implement the storage API. In this case, the CN should check the version of the read API. If that is version 1, then the archive request should proceed since the CN is authoritative for that sysmeta. If the read API is V2, then the request should fail because the MN is authoritative for the sysmeta.
PIDs to be archived include:
seadva-HsuLeslie029090a9-11b8-4fc1-bf76-bb5a8153363f
seadva-nonee903e476-9bdd-4332-823a-aabea162acd6
seadva-EssawyBakinam066de0b8-a0c9-4724-913a-9060f82148f1
seadva-EssawyBakinamc8e53366-8745-4009-bb38-786ee49cd6fe
seadva-EssawyBakinam70c6e869-5518-4c75-8d09-6a808bb41fb3
seadva-ZhouQuane9e0f510-1599-4311-a6ed-ecf803f3481f
Related issues
History
#1 Updated by Dave Vieglais over 7 years ago
- Description updated (diff)
#2 Updated by Jing Tao over 7 years ago
For v1 read-only MNs, we can allow CNs to change the system metadata object. I can image a v2 read-only MN maybe needs us to help to archive an object as well. In this approach:
If the returned version is null then the node does not implement the storage API. In this case, the CN should check the version of the read API. If that is version 1, then the archive request should proceed since the CN is authoritative for that sysmeta. If the read API is V2, then the request should fail because the MN is authoritative for the sysmeta
CNs can't help it.
#3 Updated by Dave Vieglais over 7 years ago
- Related to Task #7929: Archive content for SEAD added
#4 Updated by Jing Tao over 7 years ago
CN.setAccessPolicy
CN.setObsoletedBy
CN.setReplicationPolicy
CN.setRightsHolder
have the same issue.
After I looked at code, I found we are using the version of "MNStorage" as the version of the MN. It seems wrong. We should just use "MNRead" to determine the version of the MN.
#5 Updated by Dave Vieglais over 7 years ago
Either MNRead or MNCore. Those must be supported by any MN and should always be able to determine version.
#6 Updated by Jing Tao over 7 years ago
- % Done changed from 0 to 100
- Status changed from New to Closed
We are using MNRead to determine the version. I tested it and it worked.
#7 Updated by Dave Vieglais over 7 years ago
- Related to Task #7930: verify obsoletion in tDAR sandbox added
#8 Updated by Rob Nahf over 7 years ago
- Status changed from Closed to In Progress
- % Done changed from 100 to 30
This is not really a bug, because it is newly designed behavior when we implemented V2. Synchronization accepts system metadata changes from v1 read-only MNs as if they were V2 nodes, as was discussed and agreed upon. Checking for v1 MNStorage service was the correct way to do this.
If we want to be able to assist MNs who don't want to (or can't) make changes to their system metadata, we should limit this special access to only CN/MN administrators.
The v1.archive implementation is broken, however, in that it delegates authorization to the v2.archive implementation, which only allows CN and MN administrators. This effectively disallows object rightsHolders from updating their systemMetadata objects.
#9 Updated by Jing Tao over 7 years ago
The issue is how we determine the version of a member node. We used the storage version as the version of the member node. However, for read-only node which doesn't support the storage, the mechanism will fail since it doesn't have it. So we change to the version of the MN.READ which every member node should support.
#10 Updated by Jing Tao over 7 years ago
- % Done changed from 30 to 100
- Status changed from In Progress to Closed
Create a new ticket to address the permission issue about cn v1.archive:
https://redmine.dataone.org/issues/7964
