I looked at the top user agents and IPs in the Solr statistics for last month and I see these user agents:
“RI/1.0”, 1337
“Microsoft Office Word 2014”, 941
I will add the RI/1.0 pattern to our DSpace agents overload and purge them from Solr (we had previously seen this agent with 9,000 hits or so in 2020-09), but I think I will leave the Microsoft Word one… as that’s an actual user…
I looked at the top user agents and IPs in the Solr statistics for last month and I see these user agents:
“RI/1.0”, 1337
“Microsoft Office Word 2014”, 941
I will add the RI/1.0 pattern to our DSpace agents overload and purge them from Solr (we had previously seen this agent with 9,000 hits or so in 2020-09), but I think I will leave the Microsoft Word one… as that’s an actual user…
<li>I looked at the top user agents and IPs in the Solr statistics for last month and I see these user agents:
<ul>
<li>“RI/1.0”, 1337</li>
<li>“Microsoft Office Word 2014”, 941</li>
</ul>
</li>
<li>I will add the RI/1.0 pattern to our DSpace agents overload and purge them from Solr (we had previously seen this agent with 9,000 hits or so in 2020-09), but I think I will leave the Microsoft Word one… as that’s an actual user…</li>
</ul>
<ul>
<li>I should probably add the <code>RI/1.0</code> pattern to COUNTER-Robots project</li>
<li>As well as these IPs:
<ul>
<li>193.169.254.178, 21648</li>
<li>181.62.166.177, 20323</li>
<li>45.146.166.180, 19376</li>
</ul>
</li>
<li>The first IP seems to be in Estonia and their requests to the REST API change user agents from curl to Mac OS X to Windows and more
<ul>
<li>Also, they seem to be trying to exploit something:</li>
<li>I set up a clean DSpace 6.4 instance locally to test some things against, for example to be able to rule out whether some issues are due to Atmire modules or are fixed in the as-of-yet-unreleased DSpace 6.4
<ul>
<li>I had to delete all the Atmire schemas, then it worked fine on Tomcat 8.5 with Mirage (I didn’t want to bother with npm and ruby for Mirage 2)</li>
<li>Then I tried to see if I could reproduce the mapping issue that Marianne raised last month
<ul>
<li>I tried unmapping and remapping to the CGIAR Gender grants collection and the collection appears in the item view’s list of mapped collections, but not on the collection browse itself</li>
<li>Then I tried mapping to a new collection and it was the same as above</li>
<li>So this issue is really just a DSpace bug, and nothing to do with Atmire and not fixed in the unreleased DSpace 6.4</li>
<li>I will try one more time after updating the Discovery index (I’m also curious how fast it is on vanilla DSpace 6.4, though I think I tried that when I did the flame graphs in 2019 and it was miserable)</li>
</ul>
</li>
</ul>
</li>
</ul>
<pre><codeclass="language-console"data-lang="console">$ time ~/dspace64/bin/dspace index-discovery -b
~/dspace64/bin/dspace index-discovery -b 4053.24s user 53.17s system 38% cpu 2:58:53.83 total
</code></pre><ul>
<li>Nope! Still slow, and still no mapped item…
<ul>
<li>I even tried unmapping it from all collections, and adding it to a single new owning collection…</li>
</ul>
</li>
<li>Ah hah! Actually, I was inspecting the item’s authorization policies when I noticed that someone had made the item private!
<ul>
<li>After making it public again I was able to see it in the target collection</li>
</ul>
</li>
<li>The indexes on AReS Explorer are messed up after last week’s harvesting:</li>
<li>The AReS harvesting from yesterday finished, but the indexes are messed up again so I will have to fix them again before I harvest next time</li>
<li>I also spent some time looking at IWMI’s reports again
<ul>
<li>On AReS we don’t have a way to group by peer reviewed or item type other than doing “if type is Journal Article”</li>
<li>Also, we don’t have a way to check the IWMI Strategic Priorities because those are communities, not metadata…</li>
<li>We can get the collections an item is in from the <code>parentCollectionList</code> metadata, but it is saved in Elasticsearch as a string instead of a list…</li>
<li>I told them it won’t be possible to replicate their reports exactly</li>
</ul>
</li>
<li>I decided to look at the CLARISA controlled vocabularies again
<ul>
<li>They now have 6,200 institutions (was around 3,400 when I last looked in 2020-07)</li>
<li>They have updated their Swagger interface but it still requires an API key if you want to use it from curl</li>
<li>They have ISO 3166 countries and UN M.49 regions, but I notice they have some weird names like “Russian Federation (the)”, which is not in ISO 3166 as far as I can see</li>
<li>I exported a list of the institutions to look closer
<ul>
<li>I found twelve items with whitespace issues</li>
<li>There are some weird entries like <code>Research Institute for Aquaculture No1</code> and <code>Research Institute for Aquaculture No2</code></li>
<li>A few items have weird Unicode characters like U+00AD, U+200B, and U+00A0</li>
<li>I found 100+ items with multiple languages in there name like <code>Ministère de l’Agriculture, de la pêche et des ressources hydrauliques / Ministry of Agriculture, Hydraulic Resources and Fisheries</code></li>
<li>Over 600 institutions have the country in their name like <code>Ministry of Coordination of Environmental Affairs (Mozambique)</code></li>
<li>For URLs they have <code>null</code> in some places… which is weird… why not just leave it blank?</li>
</ul>
</li>
</ul>
</li>
<li>I checked the CLARISA list against ROR’s April, 2020 release (“Version 9”, on figshare, though it is version 8 in the dump):</li>
