DataONE Tasks: Issueshttps://redmine.dataone.org/https://redmine.dataone.org/favicon.ico2019-05-21T13:00:12ZDataONE Tasks
Redmine CN REST - Task #8810 (New): Verify configuration of portal certificateshttps://redmine.dataone.org/issues/88102019-05-21T13:00:12ZDave Vieglaisdave.vieglais@gmail.com
<p>Verify that the postinst scripts for dataone-cn-os-core and dataone-cn-portal are correctly setting the locations of the certificates for token signing.</p>
CN REST - Task #8809 (New): Adjust portal.properties for certificate configurationhttps://redmine.dataone.org/issues/88092019-05-21T12:57:41ZDave Vieglaisdave.vieglais@gmail.com
<p>Portal certificates are apparently currently configured in <code>/var/lib/tomcat7/webapps/portal/WEB-INF/portal.properties</code></p>
<p>This should be changed to <code>/etc/dataone/portal/portal.properties</code> to ensure persistence between .war deployments.</p>
CN REST - Bug #8740 (New): CN resolve service returning 404 for some pidshttps://redmine.dataone.org/issues/87402018-11-08T00:21:45ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>A user has reported that certain pids (all for metadata objects) return an http 404 status for the resolve service. Here is the complete list that the user tried that didn't resolve:</p>
<p><a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-arc.1343.2">https://cn.dataone.org/cn/v2/resolve/knb-lter-arc.1343.2</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-arc.1212.2">https://cn.dataone.org/cn/v2/resolve/knb-lter-arc.1212.2</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-arc.1477.2">https://cn.dataone.org/cn/v2/resolve/knb-lter-arc.1477.2</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-bnz.442.8">https://cn.dataone.org/cn/v2/resolve/knb-lter-bnz.442.8</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-pie.15.5">https://cn.dataone.org/cn/v2/resolve/knb-lter-pie.15.5</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-pie.248.1">https://cn.dataone.org/cn/v2/resolve/knb-lter-pie.248.1</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-sbc.6.13">https://cn.dataone.org/cn/v2/resolve/knb-lter-sbc.6.13</a><br>
<a href="https://cn.dataone.org/cn/v2/resolve/knb-lter-sbc.15.23">https://cn.dataone.org/cn/v2/resolve/knb-lter-sbc.15.23</a></p>
<p>The CNRead.getSystemMetadata() service returns metadata for each of these pids.</p>
Infrastructure - Bug #8655 (New): Synchronization died with OOMhttps://redmine.dataone.org/issues/86552018-07-13T11:24:16ZDave Vieglaisdave.vieglais@gmail.com
<p>d1-processing became unresponsive. cn-synchronization log showed:<br>
<code><br>
[ERROR] 2018-07-12 18:28:26,875 [ProcessDaemonTask1] (SyncObjectTaskManager:run:84) java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space<br>
java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: Java heap space<br>
at java.util.concurrent.FutureTask.report(FutureTask.java:122)<br>
at java.util.concurrent.FutureTask.get(FutureTask.java:192)<br>
at org.dataone.cn.batch.synchronization.SyncObjectTaskManager.run(SyncObjectTaskManager.java:76)<br>
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)<br>
at java.util.concurrent.FutureTask.run(FutureTask.java:266)<br>
at java.lang.Thread.run(Thread.java:748)<br>
Caused by: java.lang.OutOfMemoryError: Java heap space<br>
[ INFO] 2018-07-12 18:28:49,862 [ProcessDaemonTask1] (SyncObjectTaskManager:run:110) SyncObjectTaskManager Complete<br>
[ WARN] 2018-07-12 20:41:15,788 [hz.client.2.Listener] (NodeTopicListener:onMessage:68) urn:node:OTS_NDC- NodeTopicListener Disabl<br>
</code></p>
<p>d1-processing is running with:<br>
<code><br>
-Djava.awt.headless=true -XX:UseParallelGC -Xmx4096M -Xms1024M -Xss1280k -XX:MaxPermSize=512M<br>
</code></p>
CN REST - Bug #8630 (New): equivalentIdentity values use uppercase letters when the same person s...https://redmine.dataone.org/issues/86302018-06-26T14:15:00ZLauren Walkerwalker@nceas.ucsb.edu
<p>I would expect a username to appear exactly the same everywhere in the identity service. </p>
<p>Here is an example where the <code>equivalentIdentity</code> uses uppercase letters for the subject (UID=corinalogan,O=unaffiliated,DC=ecoinformatics,DC=org) when the <code>person</code>><code>subject</code> uses lowercase letters (uid=corinalogan,o=unaffiliated,dc=ecoinformatics,dc=org):</p>
<p><a href="https://cn.dataone.org/cn/v2/accounts/http%3A%2F%2Forcid.org%2F0000-0002-5944-906X">https://cn.dataone.org/cn/v2/accounts/http%3A%2F%2Forcid.org%2F0000-0002-5944-906X</a></p>
<pre><ns2:subjectInfo xmlns:ns2="http://ns.dataone.org/service/types/v1">
<person>
<subject>http://orcid.org/0000-0002-5944-906X</subject>
<givenName>Corina</givenName>
<familyName>Logan</familyName>
<equivalentIdentity>
UID=corinalogan,O=unaffiliated,DC=ecoinformatics,DC=org
</equivalentIdentity>
<verified>false</verified>
</person>
<person>
<subject>
uid=corinalogan,o=unaffiliated,dc=ecoinformatics,dc=org
</subject>
<givenName>Corina</givenName>
<familyName>Logan</familyName>
<equivalentIdentity>http://orcid.org/0000-0002-5944-906X</equivalentIdentity>
<verified>false</verified>
</person>
</ns2:subjectInfo>
```~~~
</pre> CN REST - Story #8364 (In Progress): Ensure portal uses correct X509 certificateshttps://redmine.dataone.org/issues/83642018-02-13T20:17:25ZChris Jonescjones@nceas.ucsb.edu
<p>We've run into issues where after an upgrade of the <code>dataone-cn-portal</code> package on the CNs, the properties pointing to the public certificate and private key are incorrectly pointing to the old GeoTrust wildcard files rather than the new Lets Encrypt files:<br>
<br>
cn.server.publiccert.filename=/etc/ssl/certs/<em>.test.dataone.org.crt<br>
cn.server.privatekey.filename=/etc/ssl/private/</em>.test.dataone.org.key</p>
<p>These should be (in STAGE):</p>
<p>/etc/letsencrypt/live/cn-stage.test.dataone.org/cert.pem<br>
/etc/letsencrypt/live/cn-stage.test.dataone.org/privkey.pem</p>
<p>The issue might be that these are not being set correctly during the <code>postinst</code> script run. Jing pointed out that these values are taken from the debconf database settings that get set when <code>dataon-cn-os-core</code> is installed. So although the <code>postinst</code> script might be setting the correct values, the old cached values might still be in memory in the debconf database. If so, we'll need to clear those values during installations and upgrades.</p>
<p>Also, knowing where to look for these configuration settings can be challenging. These are referenced from <code>/var/lib/tomcat7/webapps/portal/WEB-INF/portal.properties</code>. These settings should be consolidated into <code>/etc/dataone/portal/portal.properties</code> so they also don't get blown away on war file upgrades in Tomcat.</p>
Infrastructure - Bug #7919 (New): unloadable system metadata in CNs by Hazelcasthttps://redmine.dataone.org/issues/79192016-10-26T16:22:56ZRob Nahfrnahf@epscor.unm.edu
<p>Looking through the metacat logs, I found a lot of instances where the HzSystemMetadataMap could not load system metadata for particular pids. Most had dryad in the pid (~1200), but another 130 are from elsewhere.</p>
<p>a random sample showed that it couldn't be retrieved via /meta although the pid could be retrieved from the Dryad MN.</p>
<p>This appears to be another type of half-created content on the CN.</p>
<p>rnahf@cn-ucsb-1:~$ grep 'could not load system metadata' /var/metacat/logs/metacat.log | cut -c60- | sort | uniq | grep -v dryad | wc -l<br>
139<br>
rnahf@cn-ucsb-1:~$ grep 'could not load system metadata' /var/metacat/logs/metacat.log | cut -c60- | sort | uniq | grep dryad | wc -l<br>
1216</p>
CN REST - Task #7911 (New): Synchronization allows invalid checksums, preventing corrected synchttps://redmine.dataone.org/issues/79112016-10-17T15:16:07ZChris Jonescjones@nceas.ucsb.edu
<p>Normally, d1_synchronization does checksum validation of objects before registering them in the CN. However, a CHECKSUM_VERIFICATION_SIZE_BYPASS_THRESHOLD flag was introduced into TransferObjectTask that defaults to 10MB. If an object size is greater than this threshold, the checksum won't be verified. In the cn-buildout, this default is not changed in the properties file, but it can be.</p>
<p>As a result, objects below this threshold will throw an exception during sync if the checksum is incorrect, whereas those above the threshold will successfully sync with incorrect system metadata. This becomes a problem later when trying to update the system metadata with the correct checksum because this field is immutable. For example, in the STAGE environment, the following object failed to process the system metadata update:</p>
<p>[ERROR] 2016-10-17 14:54:38,112 (V2TransferObjectTask:call:269) Task-urn:node:mnTestARCTIC-urn:uuid:a3bfef74-f6e9-4ecc-871e-0a3ea764b471 - UnrecoverableException: Failed to update cn with new valid SystemMetadata! - InvalidRequest - The request is trying to modify an immutable field in the SystemMeta: the new system meta's checksum dee03804421bac149371877d2d366abb7c941fba is different to the orginal one bef6df568ed1c713a8323434694319894f25a8b9dfa704f7fe2b7d52592b2b40</p>
<p>Since MN.getChecksum() is normally being called to do the heavy lifting of calculating the actual checksum, I'm not sure why this flag was introduced. Even for muti-gigabyte files, the checksum calculation is pretty quick. To prevent the CN from ingesting incorrect system metadata, I'd suggest we consider removing this threshold, or at a minimum, set the property value to be multi-terabyte. Also, this is a case where the MN is authoritative for the system metadata, but the CN update fails because of the immutable status of the checksum. Ultimately, we shouldn't be sync'ing content with invalid checksums, which allows for the MN operator to correct the checksum and then retry the sync. Needs discussion.</p>
CN REST - Task #7750 (New): apply business rules on the CN that Subject strings will be stripped ...https://redmine.dataone.org/issues/77502016-04-26T17:30:35ZRob Nahfrnahf@epscor.unm.edu
<p>make sure that the business rule is documented</p>
<p>apply to cn_identity_manager and other places in the CN service layer.</p>
CN REST - Task #7571 (New): Description for error code 401, detail code 4957 is misleading in som...https://redmine.dataone.org/issues/75712016-01-05T16:25:01ZPeter Slaughterslaughter@nceas.ucsb.edu
<p>When using CNDiagnostic.echoCredentials() with an expired authentication token, the returned message is:</p>
<p><?xml version="1.0" encoding="UTF-8"?><br>
<br>
No credentials were received in the request. (Session was null)</p>
<p>The description text in this case is misleading, because from the caller's point of view, credentials<br>
were provided, albeit invalid. Is it possible to determine the validity of the credentials, i.e. expiration<br>
status, and indicate that in the description?</p>
<p>BTW, this same token did work correctly before it expired.</p>
<p>A bash script is attached that recreates the error.</p>
CN REST - Bug #7440 (New): Non-discernable error during synchronization affecting (mostly) urn:no...https://redmine.dataone.org/issues/74402015-10-16T17:40:44ZMark Servillamark.servilla@gmail.com
<p>Multiple (366) non-discernable errors (see attachment) with message only stating "Cline is shutdown" occurred on 14 Oct 2015 on cn-stage.test.dataone.org (cn-stage-ucsb-1); sampling of objects/system metadata indicate all is retrievable from the MN <a href="https://dataone-dev.ecoinformatics.org.au/mn">https://dataone-dev.ecoinformatics.org.au/mn</a>. This error had also occurred (24 events) for urn:node:mnTestLTER.</p>
<p>For example:</p>
<p>cn-synchronization.log.1-[ERROR] 2015-10-14 11:33:02,749 (TransferObjectTask:write:606) Task-urn:node:mnTestAEKOS-aekos.org.au/collection/nsw.gov.au/nsw_atlas/vis_flora_module/ABERBALDIE.20150515<br>
cn-synchronization.log.1:Client is shutdown.</p>
CN REST - Bug #7301 (New): CN-stage allows connections to a MN that is operating a self-signed SS...https://redmine.dataone.org/issues/73012015-08-18T18:12:14ZMark Servillamark.servilla@gmail.com
<p>CN-stage supports connections to a MN that is operating a self-signed SSL server certificate - this should not be allowed since the connection could occur with a rogue non-verified server.</p>
<p>This instance occurred with dataone-dev.ecoinformatics.org.au:443 on 18 August 2015:</p>
<p>Certificate chain<br>
0 s:/CN=dataone-dev.ecoinformatics.org.au<br>
i:/CN=dataone-dev.ecoinformatics.org.au</p>
<p>Issuer: CN=dataone-dev.ecoinformatics.org.au<br>
Validity<br>
Not Before: Aug 11 04:56:19 2015 GMT<br>
Not After : Aug 8 04:56:19 2025 GMT<br>
Subject: CN=dataone-dev.ecoinformatics.org.au</p>
CN REST - Bug #7161 (New): TERN object fails to be indexed by Solr, but successfully synchronizedhttps://redmine.dataone.org/issues/71612015-06-05T18:02:10ZMark Servillamark.servilla@gmail.com
<p>TERN object aekos.org.au/collection/nsw.gov.au/nsw_atlas/vis_flora_module/V_ILLAWDB3.20150515 fails to by indexed by Solr on cn.dataone.edu (cn-ucsb-1) even though it was successfully synchronized. Investigation indicates it was not added to the HazelCast ObjectPathMap structure according to Skye Roseboom:</p>
<p>Im not sure why this pid is not appearing in the hazelcast ObjectPathMap structure.</p>
<p>I looked into the metacat database schema a bit and noticed the pid does not seem to appear in the ‘identifier_mapping’ table:</p>
<p>select * from identifier_mapping where guid='aekos.org.au/collection/nsw.gov.au/nsw_atlas/vis_flora_module/V_ILLAWDB3.20150515';</p>
<table><thead>
<tr>
<th>guid</th>
<th>docid</th>
<th>rev</th>
</tr>
</thead><tbody>
</tbody></table>
<p>(0 rows)</p>
<p>Without the ‘docid’ or ‘localid’ as metacat calls them, Im don’t thing the pid could be added to the objectPathMap in hazelcast.</p>
Member Nodes - Task #3906 (New): Update malformed Resource Mapshttps://redmine.dataone.org/issues/39062013-08-09T17:50:27ZRob Nahfrnahf@epscor.unm.edu
<p>Update all existing resource maps in Merritt and ONShare MNs so that URIs are used instead of object-literals, to create valid resource maps. </p>
Infrastructure - Task #1556 (In Progress): Interns mailing listhttps://redmine.dataone.org/issues/15562011-05-12T20:19:01ZAmber Buddenaebudden@gmail.com
<p>Can you please clear the current 'interns' mailing list in preparation for use in 2011. It currently sends out to last years interns. Once the new interns have set up plone accounts I will submit a new request to have them added.</p>