DataONE Tasks: Issueshttps://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2020-09-16T20:42:07ZDataONE Tasks
Redmine Infrastructure - Story #8869 (New): Equivalent identities show owning different amount of package...https://redmine.dataone.org/issues/88692020-09-16T20:42:07ZJing Taotao@nceas.ucsb.edu
<p>Matt reported he could see 188 packages listed as <code>My Dataset</code> on the profile page of KNB, which including two packages he created as his ORCID, when he logged in by his ldap account. However, he only could see two packages when he logged in by his ORCID even though the two identities are set to be equivalent:<br>
<a href="https://cn.dataone.org/cn/v2/accounts/http%3A%2F%2Forcid.org%2F0000-0003-0077-4738">https://cn.dataone.org/cn/v2/accounts/http%3A%2F%2Forcid.org%2F0000-0003-0077-4738</a></p>
<p>It seems the equivalent identities are not commutative.</p>
<p>Matt also noticed that the equivalent ldap id for his ORCID is <code>UID=jones,O=NCEAS,DC=ecoinformatics,DC=org</code>, which uses <code>UID</code> rather than <code>uid</code>. He suspected this is the issue to cause the problem.</p>
CN REST - Bug #8867 (New): CNCore.listChecksumAlgorithms() returns incorrect listhttps://redmine.dataone.org/issues/88672020-08-06T00:06:07ZMatthew Jonesjones@nceas.ucsb.edu
<p>The definition of the ChecksumAlgorithm type in SystemMetadata allows any checksum algorithm listed in the Library of Congress vocab. But the current CNCore.listChecksumAlgorithms() implementation only returns two, MD5 and SHA-1. Need to correct this to include the full list of supported algorithms (see <a href="http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions.html">http://id.loc.gov/vocabulary/preservation/cryptographicHashFunctions.html</a>).</p>
<p>The implementation of this is in a property file, which needs to be updated with the correct list. The file (d1_cn_rest/src/test/resources/org/dataone/configuration/node.properties) currently contains:</p>
<p><code>cn.checksumAlgorithmList=SHA-1;MD5</code></p>
<p>But it should contain all of the other valid algorithms as well from the LoC.</p>
Infrastructure - Bug #8866 (New): Java client tools should set a custom user agent stringhttps://redmine.dataone.org/issues/88662020-07-15T18:03:40ZBryce Mecummecum@nceas.ucsb.edu
<p>Related to <a href="https://redmine.dataone.org/issues/7047">https://redmine.dataone.org/issues/7047</a></p>
<p>It looks like nowhere in <code>d1_libclient_java</code> do we set a user agent string. Aside from being best practice, it limits our ability to customize our infrastructure around it. For example, OPC is running into HTTP 413s due to overrunning their TLS renegotiation buffer and we can't effectively whitelist their requests, which come from our Java client tools, to allow them to upload large files.</p>
CN REST - Story #8864 (New): Sychronization does not register authoritative replica entry correctlyhttps://redmine.dataone.org/issues/88642020-06-17T21:49:55ZChris Jonescjones@nceas.ucsb.edu
<p>When objects are synchronized to the CN, the <code>d1_synchronization</code> component will fetch the system metadata <br>
for each object and will add a <code><replica></code> entry for the origin node (like <code>urn:node:ESS_DIVE</code>, <br>
as well as entries for other copies (for instance for science metadata copied to the CN, <br>
a <code><replica>urn:node:CN</replica></code> will be added.</p>
<p>In some instances, the origin replica instance is not added to the replica list.<br><br>
This causes downstream problems for the <code>d1_replication</code> component because it relies on the origin node <br>
replica entry to be present in order to set up a replication request to a target node. I'm seeing errors like:</p>
<pre>/var/log/dataone/replicate/cn-replication.log.90:[ERROR] 2020-06-04 05:18:30,179 [pool-15-thread-1] (MNCommunication:requestReplication:34) Could not determine replication source node for replication request for pid: ess-dive-eb6cbb22c605506-20200122T170607966. Replication request failed.
</pre>
<p>Looking back in the logs, this is the case for the following objects:</p>
<pre>ess-dive-3947e68e9825233-20180621T213650539
ess-dive-3b8d9f4513e02f9-20180621T214221437
ess-dive-467a6c3dda4dc88-20180621T211148554
ess-dive-51f345daca126f7-20180328T160350610716
ess-dive-53b37ae5d8c0f51-20200219T211634419654
ess-dive-6b688fab5524c46-20200121T210154766
ess-dive-7a31346c154f02b-20200127T155012488
ess-dive-a1fb05cbd903309-20200130T190835651
ess-dive-b420b097851c716-20180523T161714606
ess-dive-ba81a8a8e0bef31-20180727T200828345
ess-dive-bfaf3d6d6fd038c-20180716T154005175903
ess-dive-c2ef5f3af108c9c-20180621T220020545
ess-dive-eb6cbb22c605506-20200122T170607966
ess-dive-f3238db16593de5-20180621T215956950
</pre>
<p>We need to fix this issue in <code>d1_synchronization</code> so replication runs correctly and monthly <br>
replica auditing (done by ESS_DIVE) doesn't flag these issues.</p>
Infrastructure - Story #8862 (New): Deploy a new dataone-cn-rest releasehttps://redmine.dataone.org/issues/88622020-04-23T16:24:46ZJing Taotao@nceas.ucsb.edu
<p>We have a new d1_portal jar release which addresses the issue that restarting tomcat in CNs is needed when the LE certificates are renewed in CNs. The new d1_portal jar file has been deployed to dataone-cn-portal. However, the component dataone-cn-rest was overlooked. We need to deploy it there as well.<br>
Yesterday, we did a hack fix in CNs when we restarted tomcat - dropped the d1_portal-2.3.2.jar file there. So now it should work. But we still need a formal release.</p>
CN REST - Bug #8860 (New): /token endpoint doesn't set a content-type and character encodinghttps://redmine.dataone.org/issues/88602020-02-29T01:00:11ZBryce Mecummecum@nceas.ucsb.edu
<p>On Firefox only, requests to the /portal/token endpoint (i.e., the one MetacatUI and other clients use to fetch their auth tokens, like <a href="https://cn.dataone.org/portal/token">https://cn.dataone.org/portal/token</a>) result in errors in the browser console.</p>
<p>When you access the URL via an XHR request, you see:</p>
<blockquote>
<p>XML Parsing Error: syntax error<br>
Location: <a href="https://cn-stage.test.dataone.org/portal/token">https://cn-stage.test.dataone.org/portal/token</a><br>
Line Number 1, Column 1:</p>
</blockquote>
<p>When you access the URL directly in Firefox:</p>
<blockquote>
<p>The character encoding of the plain text document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the file needs to be declared in the transfer protocol or file needs to use a byte order mark as an encoding signature.</p>
</blockquote>
<p>I had a hunch that this error would go away if the response simply had the <code>Content-Type</code> header set to <code>text/plain; charset=utf-8</code> so I spun up <code>mitmproxy</code>, made that edit to the intercepted response, and saw that the error does go away.</p>
<p>I think we should modify the portal code to set the <code>Content-Type</code> header like above so the error goes away.</p>
Infrastructure - Task #8858 (New): Update CN Apache configs in version control with directives to...https://redmine.dataone.org/issues/88582020-02-05T20:02:12ZBryce Mecummecum@nceas.ucsb.edu
<p>Sitemaps are located on disk in ${tomcat_webapps_dir}/${context}/sitemaps as <code>sitemap_index.xml</code> and <code>sitemap%d.xml</code> (for each sub-sitemap).</p>
<p>The rule we've come up with is:</p>
<p><code>RewriteRule ^/(sitemap.+) /metacat/sitemaps/$1 [R=303]</code></p>
Infrastructure - Story #8857 (New): D1Client.getCN() always get the production cn on the CN Tomca...https://redmine.dataone.org/issues/88572019-12-13T00:34:03ZJing Taotao@nceas.ucsb.edu
<p>Today Val from ess-dive reported an issue that in the cn-stage environment, the rest call <code>cn/v2/diag/subject</code> didn't return any group information for a user even though the <code>cn/v2/accounts</code> call proves the user is in some groups.</p>
<p>After looking at the code, it seems suspicious that the <code>cn/v2/diag/subject</code> uses the method <code>D1Client.getCN().getSubjectInfo(subject)</code> to get the suer information. I guess it aways uses the production cn rather than the cn-stage. I put the property <code>D1Client.CN_URL=https://cn-stage.test.dataone.org/cn</code> on the file <code>/var/lib/tomcat8/webapps/cn/WEB-INF/classes/org/dataone/configuration/portal.properties</code>, then it works.</p>
<p>So we need to set up the property during our package building process.</p>
Infrastructure - Story #8856 (New): Put the system metadata part ahead of the object part when d1...https://redmine.dataone.org/issues/88562019-11-22T18:31:19ZJing Taotao@nceas.ucsb.edu
<p>When a client calls the mn.create/update methods, it usually constructs a multipart which contains the sys part (containing the system metadata information), object part (containing the object itself) and other parts. There is no requirement about the order of those parts.<br>
Metacat will use a new streaming multipart handler which will calculate the checksum when it stores the object part into a file. This requires we should know the checksum algorithm before the serialization of the object. So Metacat has to digest the system metadata first in order to improve the performance.<br>
In order to take the advantage, we recommend clients should put the system metadata part ahead of the object part when it is constructing the multipart to be sent to the server.<br>
Note: event though the client doesn't use the recommended order, the process still works but the performance will be poor.</p>
Infrastructure - Story #8855 (New): Put the system metadata part ahead of the object part when d1...https://redmine.dataone.org/issues/88552019-11-22T18:29:39ZJing Taotao@nceas.ucsb.edu
<p>When a client calls the mn(cn).create/update methods, it usually constructs a multipart which contains the sys part (containing the system metadata information), object part (containing the object itself) and other parts. There is no requirement about the order of those parts.<br>
Metacat will use a new streaming multipart handler which will calculate the checksum when it stores the object part into a file. This requires we should know the checksum algorithm before the serialization of the object. So Metacat has to digest the system metadata first in order to improve the performance.<br>
In order to take the advantage, we recommend clients should put the system metadata part ahead of the object part when it is constructing the multipart to be sent to the server.<br>
Note: event though the client doesn't use the recommended order, the process still works but the performance will be poor.</p>
Infrastructure - Story #8854 (New): Put the system metadata part ahead of the object part when d...https://redmine.dataone.org/issues/88542019-11-22T18:25:20ZJing Taotao@nceas.ucsb.edu
<p>When a client calls the mn.create/update methods, it usually constructs a multipart which contains the sys part (containing the system metadata information), object part (containing the object itself) and other parts. There is no requirement about the order of those parts.<br>
Metacat will use a new streaming multipart handler which will calculate the checksum when it stores the object part into a file. This requires we should know the checksum algorithm before the serialization of the object. So Metacat has to digest the system metadata first in order to improve the performance.<br>
In order to take the advantage, we recommend clients should put the system metadata part ahead of the object part when it is constructing the multipart to be sent to the server.<br>
Note, event thought the client doesn't use the recommended order, the process still works but the performance will be poor.</p>
Infrastructure - Story #8853 (New): Make cn.resolve smarterhttps://redmine.dataone.org/issues/88532019-11-15T16:46:12ZJing Taotao@nceas.ucsb.edu
<p>In this case the cn.resolve() operation should be ignoring the node that is marked as offline, or at least placing it last in the list.</p>
<p>This should be a high priority fix, and should be fairly simple to implement since the information is available in the node document.</p>
<ul>
<li>Dave</li>
</ul>
<blockquote>
<p>On 2019-11-14, at 21:38, Matt Jones <a href="mailto:jones@nceas.ucsb.edu">jones@nceas.ucsb.edu</a> wrote:</p>
<p>FYI, thread form today with Ethan White on ebird replication, and the resolve() api in DataONE. Relates to our conversation today about making resolve() and MetacatUI downloads smarter.</p>
<p>Matt</p>
<p>Ethan White 5:06 PM<br>
What's the right place to report data that if 404ing on DataONE?</p>
<p>Matt Jones 5:07 PM<br>
<a href="mailto:support@dataone.org">support@dataone.org</a> would work</p>
<p>5:08 PM<br>
or let me know</p>
<p>5:08 PM<br>
is it that same data set?</p>
<p>5:08 PM<br>
the Ebird one?</p>
<p>Ethan White 5:09 PM<br>
Yeah, which we had discovered had been reposted and spent a bunch of time gearing up to support again. We were in the middle of testing when it suddenly disappeared again. <a href="http://dataone.ornith.cornell.edu/metacat/d1/mn/v2/object/EOD_CLO_2016.csv.gz">http://dataone.ornith.cornell.edu/metacat/d1/mn/v2/object/EOD_CLO_2016.csv.gz</a></p>
<p>Matt Jones 5:10 PM<br>
yeah. Cornell just gave us permission to replicate the data to other nodes. They haven’t wanted us to do so in the past.</p>
<p>Ethan White 5:13 PM<br>
Thanks. That's good news. So can we expect it to reappear at some point soonish?</p>
<p>Matt Jones 5:14 PM<br>
Yeah, its been replicated. I’m checking to see if it is properly linked to the original.</p>
<p>5:15 PM<br>
<a href="https://knb.ecoinformatics.org/view/EOD_CLO_2016.eml">https://knb.ecoinformatics.org/view/EOD_CLO_2016.eml</a></p>
<p>new messages</p>
<p>Ethan White 5:16 PM<br>
Thanks Matt. FYI that link I posted is the one being returned from a current search of DataONE.</p>
<p>Matt Jones 5:17 PM<br>
Yeah. Because that’s the ‘authoritative’ copy at cornell.</p>
<p>5:17 PM<br>
but Cornell’s node has been going up and down.</p>
<p>5:17 PM<br>
our resolve service lists all copies of a data set</p>
<p>5:17 PM<br>
so if one is down, you can get it from another location:</p>
<p>5:18 PM<br>
<code><br>
$ curl -H "Accept: text/xml" https://cn.dataone.org/cn/v2/resolve/EOD_CLO_2016.eml<br>
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><br>
<ns2:objectLocationList xmlns:ns2="http://ns.dataone.org/service/types/v1"><br>
<identifier>EOD_CLO_2016.eml</identifier><br>
<objectLocation><br>
<nodeIdentifier>urn:node:CLOEBIRD</nodeIdentifier><br>
<baseURL>http://dataone.ornith.cornell.edu/metacat/d1/mn</baseURL><br>
<version>v1</version><br>
<version>v2</version><br>
<url>http://dataone.ornith.cornell.edu/metacat/d1/mn/v2/object/EOD_CLO_2016.eml</url><br>
</objectLocation><br>
<objectLocation><br>
<nodeIdentifier>urn:node:CN</nodeIdentifier><br>
<baseURL>https://cn.dataone.org/cn</baseURL><br>
<version>v1</version><br>
<version>v2</version><br>
<url>https://cn.dataone.org/cn/v2/object/EOD_CLO_2016.eml</url><br>
</objectLocation><br>
<objectLocation><br>
<nodeIdentifier>urn:node:KNB</nodeIdentifier><br>
<baseURL>https://knb.ecoinformatics.org/knb/d1/mn</baseURL><br>
<version>v1</version><br>
<version>v2</version><br>
<url>https://knb.ecoinformatics.org/knb/d1/mn/v2/object/EOD_CLO_2016.eml</url><br>
</objectLocation><br>
</ns2:objectLocationList><br>
</code></p>
<p>Ethan White 5:19 PM<br>
OK, thanks. That's why I thought the link in DataONE <a href="https://cn.dataone.org/cn/v2/resolve/EOD_CLO_2016.csv.gz">https://cn.dataone.org/cn/v2/resolve/EOD_CLO_2016.csv.gz</a> would take me to a working version, but clearly I just don't understand the details. We'll just use the the one on KNB at least for the moment. Really appreciate your help as always.</p>
<p>Matt Jones 5:20 PM<br>
No problem. I’d love to make this all work more seamlessly. (edited) </p>
<p>5:20 PM<br>
So suggestions definitely welcome.</p>
<p>5:21 PM<br>
I expect Cornell to take their node offline altogether — so the KNB will likely be the better location.</p>
<p>5:22 PM<br>
Btw, the resolve link when executed in a browser just redirects to the first copy</p>
<p>Ethan White 5:23 PM<br>
Yeah, Cornell's closed approach to things is a pretty big disappointment, especially on data like this that is generated by volunteers. We'll just go to the KNB version permanently.</p>
<p>Matt Jones 5:23 PM<br>
whereas programatically you get the list of locations</p>
<p>5:23 PM<br>
if you ask for XML</p>
<p>Ethan White 5:23 PM<br>
That makes sense. Thanks.</p>
<p>Matt Jones 5:23 PM<br>
and then you can choose to try one or more</p>
</blockquote>
Infrastructure - Story #8851 (New): CN sends error doc with "pid" to v2 endpointhttps://redmine.dataone.org/issues/88512019-11-06T22:31:11ZRoger Dahldahl@unm.edu
<p>Error XML type with "pid" is correct re. 2.0 arch docs but not 2.0 schemas. Let's discuss in maint. call.</p>
<ul>
<li>2.0 arch doc says 'pid': <a href="https://releases.dataone.org/online/api-documentation-v2.0/apis/Exceptions.html#Exceptions.SynchronizationFailed">https://releases.dataone.org/online/api-documentation-v2.0/apis/Exceptions.html#Exceptions.SynchronizationFailed</a></li>
<li>1.1 schema says 'pid': <a href="https://releases.dataone.org/online/d1-schemas-1.1.1/dataoneErrors.xsd">https://releases.dataone.org/online/d1-schemas-1.1.1/dataoneErrors.xsd</a> </li>
<li>2.0 schema says 'identifier': <a href="https://releases.dataone.org/online/d1-schemas-2.0.1/dataoneErrors.xsd">https://releases.dataone.org/online/d1-schemas-2.0.1/dataoneErrors.xsd</a>
<ul>
<li>Presumably because it can be a PID or a SID</li>
</ul></li>
<li>GMN expects "pid" in /v1 and "identifier" in /v2</li>
</ul>
<p>Example error sent to GMN v2 MNRead.synchronizationFailed() by the CN:</p>
<p><?xml version="1.0" encoding="UTF-8"?><br>
<br>
Synchronization task of [PID::] <a href="https://pasta.lternet.edu/package/data/eml/edi/443/1/0271719552fcd1ce830fcb2ee8efae71">https://pasta.lternet.edu/package/data/eml/edi/443/1/0271719552fcd1ce830fcb2ee8efae71</a> [::PID] failed. Cause: InvalidSystemMetadata: The checksum for pid: <a href="https://pasta.lternet.edu/package/data/eml/edi/443/1/0271719552fcd1ce830fcb2ee8efae71">https://pasta.lternet.edu/package/data/eml/edi/443/1/0271719552fcd1ce830fcb2ee8efae71</a> does not match the actual checksum supplied by the member node: urn:node:EDI. Actual checksum: null. System metadata checksum: eaaac8b49e6e8c13d30005a69e3600e7e17c9b3a</p>
Infrastructure - Bug #8850 (New): v2.3.11 RdfXmlSubprocessor / HttpService.getDocumentBySeriesId...https://redmine.dataone.org/issues/88502019-11-06T18:29:30ZRob Nahfrnahf@epscor.unm.edu
<p>branch D1_CN_INDEX_PROCESSOR_v2.3 introduced a new method HttpService.getDocumentBySeriesId, to be used by RdfXmlSubprocessor to get the head of a series.</p>
<p>It is buggy in that it determines the head of the series based only on the value of the obsoletedBy field, and in the index, more than one solr document can fit that criteria. The simple case (and that is likely to be enriched in multi-threaded indexing) is when the systemMetadata update of an update of an object is processed at some future time after the indexing of the update itself. When indexing the update, both the update and the original would be returned from Solr, and the client method would return which ever one happened to be first in the list.</p>
<p>The v2.4 indexer which uses "total relationship enumeration," will not use this method, so fixing this bug is only important if the 2.3 logic will be maintained.</p>
<p>If it will be maintained, it's important to note that the DataONE spec does not require the obsoletedBy field to be populated, although Metacat does. Mutable MemberNodes my never update the obsoletedBy field of those objects not at the head. Similar logic implemented for resolve should be considered for these cases.</p>
Infrastructure - Story #8849 (New): During sync, the CN does not detect error returned from getCh...https://redmine.dataone.org/issues/88492019-11-05T19:25:48ZRoger Dahldahl@unm.edu
<p>Due to a bug, GMN returned 500 on some getChecksum() calls. The CN did not detect the 500 return status and proceeded with the sync, using "null" as the checksum.</p>