mirror of
https://github.com/alanorth/cgspace-notes.git
synced 2024-11-05 23:03:00 +01:00
838 lines
33 KiB
HTML
838 lines
33 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
|
||
|
||
<meta property="og:title" content="November, 2017" />
|
||
<meta property="og:description" content="2017-11-01
|
||
|
||
|
||
The CORE developers responded to say they are looking into their bot not respecting our robots.txt
|
||
|
||
|
||
2017-11-02
|
||
|
||
|
||
Today there have been no hits by CORE and no alerts from Linode (coincidence?)
|
||
|
||
|
||
# grep -c "CORE" /var/log/nginx/access.log
|
||
0
|
||
|
||
|
||
|
||
Generate list of authors on CGSpace for Peter to go through and correct:
|
||
|
||
|
||
dspace=# \copy (select distinct text_value, count(*) as count from metadatavalue where metadata_field_id = (select metadata_field_id from metadatafieldregistry where element = 'contributor' and qualifier = 'author') AND resource_type_id = 2 group by text_value order by count desc) to /tmp/authors.csv with csv;
|
||
COPY 54701
|
||
|
||
|
||
" />
|
||
<meta property="og:type" content="article" />
|
||
<meta property="og:url" content="https://alanorth.github.io/cgspace-notes/2017-11/" />
|
||
|
||
|
||
|
||
<meta property="article:published_time" content="2017-11-02T09:37:54+02:00"/>
|
||
|
||
<meta property="article:modified_time" content="2017-11-12T10:19:47+02:00"/>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<meta name="twitter:card" content="summary"/><meta name="twitter:title" content="November, 2017"/>
|
||
<meta name="twitter:description" content="2017-11-01
|
||
|
||
|
||
The CORE developers responded to say they are looking into their bot not respecting our robots.txt
|
||
|
||
|
||
2017-11-02
|
||
|
||
|
||
Today there have been no hits by CORE and no alerts from Linode (coincidence?)
|
||
|
||
|
||
# grep -c "CORE" /var/log/nginx/access.log
|
||
0
|
||
|
||
|
||
|
||
Generate list of authors on CGSpace for Peter to go through and correct:
|
||
|
||
|
||
dspace=# \copy (select distinct text_value, count(*) as count from metadatavalue where metadata_field_id = (select metadata_field_id from metadatafieldregistry where element = 'contributor' and qualifier = 'author') AND resource_type_id = 2 group by text_value order by count desc) to /tmp/authors.csv with csv;
|
||
COPY 54701
|
||
|
||
|
||
"/>
|
||
<meta name="generator" content="Hugo 0.30.2" />
|
||
|
||
|
||
|
||
<script type="application/ld+json">
|
||
{
|
||
"@context": "http://schema.org",
|
||
"@type": "BlogPosting",
|
||
"headline": "November, 2017",
|
||
"url": "https://alanorth.github.io/cgspace-notes/2017-11/",
|
||
"wordCount": "3150",
|
||
"datePublished": "2017-11-02T09:37:54+02:00",
|
||
"dateModified": "2017-11-12T10:19:47+02:00",
|
||
"author": {
|
||
"@type": "Person",
|
||
"name": "Alan Orth"
|
||
},
|
||
"keywords": "Notes"
|
||
}
|
||
</script>
|
||
|
||
|
||
|
||
<link rel="canonical" href="https://alanorth.github.io/cgspace-notes/2017-11/">
|
||
|
||
<title>November, 2017 | CGSpace Notes</title>
|
||
|
||
<!-- combined, minified CSS -->
|
||
<link href="https://alanorth.github.io/cgspace-notes/css/style.css" rel="stylesheet" integrity="sha384-O8wjsnz02XiyrPxnhfF6AVOv6YLBaEGRCnVF+DL3gCPBy9cieyHcpixIrVyD2JS5" crossorigin="anonymous">
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
</head>
|
||
|
||
<body>
|
||
|
||
<div class="blog-masthead">
|
||
<div class="container">
|
||
<nav class="nav blog-nav">
|
||
<a class="nav-link " href="https://alanorth.github.io/cgspace-notes/">Home</a>
|
||
|
||
|
||
</nav>
|
||
</div>
|
||
</div>
|
||
|
||
<header class="blog-header">
|
||
<div class="container">
|
||
<h1 class="blog-title"><a href="https://alanorth.github.io/cgspace-notes/" rel="home">CGSpace Notes</a></h1>
|
||
<p class="lead blog-description">Documenting day-to-day work on the <a href="https://cgspace.cgiar.org">CGSpace</a> repository.</p>
|
||
</div>
|
||
</header>
|
||
|
||
<div class="container">
|
||
<div class="row">
|
||
<div class="col-sm-8 blog-main">
|
||
|
||
|
||
|
||
|
||
<article class="blog-post">
|
||
<header>
|
||
<h2 class="blog-post-title"><a href="https://alanorth.github.io/cgspace-notes/2017-11/">November, 2017</a></h2>
|
||
<p class="blog-post-meta"><time datetime="2017-11-02T09:37:54+02:00">Thu Nov 02, 2017</time> by Alan Orth in
|
||
|
||
<i class="fa fa-tag" aria-hidden="true"></i> <a href="/cgspace-notes/tags/notes" rel="tag">Notes</a>
|
||
|
||
</p>
|
||
</header>
|
||
<h2 id="2017-11-01">2017-11-01</h2>
|
||
|
||
<ul>
|
||
<li>The CORE developers responded to say they are looking into their bot not respecting our robots.txt</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-02">2017-11-02</h2>
|
||
|
||
<ul>
|
||
<li>Today there have been no hits by CORE and no alerts from Linode (coincidence?)</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c "CORE" /var/log/nginx/access.log
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Generate list of authors on CGSpace for Peter to go through and correct:</li>
|
||
</ul>
|
||
|
||
<pre><code>dspace=# \copy (select distinct text_value, count(*) as count from metadatavalue where metadata_field_id = (select metadata_field_id from metadatafieldregistry where element = 'contributor' and qualifier = 'author') AND resource_type_id = 2 group by text_value order by count desc) to /tmp/authors.csv with csv;
|
||
COPY 54701
|
||
</code></pre>
|
||
|
||
<p></p>
|
||
|
||
<ul>
|
||
<li>Abenet asked if it would be possible to generate a report of items in Listing and Reports that had “International Fund for Agricultural Development” as the <em>only</em> investor</li>
|
||
<li>I opened a ticket with Atmire to ask if this was possible: <a href="https://tracker.atmire.com/tickets-cgiar-ilri/view-ticket?id=540">https://tracker.atmire.com/tickets-cgiar-ilri/view-ticket?id=540</a></li>
|
||
<li>Work on making the thumbnails in the item view clickable</li>
|
||
<li>Basically, once you read the METS XML for an item it becomes easy to trace the structure to find the bitstream link</li>
|
||
</ul>
|
||
|
||
<pre><code>//mets:fileSec/mets:fileGrp[@USE='CONTENT']/mets:file/mets:FLocat[@LOCTYPE='URL']/@xlink:href
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>METS XML is available for all items with this pattern: /metadata/handle/10568/95947/mets.xml</li>
|
||
<li>I whipped up a quick hack to print a clickable link with this URL on the thumbnail but it needs to check a few corner cases, like when there is a thumbnail but no content bitstream!</li>
|
||
<li>Help proof fifty-three CIAT records for Sisay: <a href="https://dspacetest.cgiar.org/handle/10568/95895">https://dspacetest.cgiar.org/handle/10568/95895</a></li>
|
||
<li>A handful of issues with <code>cg.place</code> using format like “Lima, PE” instead of “Lima, Peru”</li>
|
||
<li>Also, some dates like with completely invalid format like “2010- 06” and “2011-3-28”</li>
|
||
<li>I also collapsed some consecutive whitespace on a handful of fields</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-03">2017-11-03</h2>
|
||
|
||
<ul>
|
||
<li>Atmire got back to us to say that they estimate it will take two days of labor to implement the change to Listings and Reports</li>
|
||
<li>I said I’d ask Abenet if she wants that feature</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-04">2017-11-04</h2>
|
||
|
||
<ul>
|
||
<li>I finished looking through Sisay’s CIAT records for the “Alianzas de Aprendizaje” data</li>
|
||
<li>I corrected about half of the authors to standardize them</li>
|
||
<li>Linode emailed this morning to say that the CPU usage was high again, this time at 6:14AM</li>
|
||
<li>It’s the first time in a few days that this has happened</li>
|
||
<li>I had a look to see what was going on, but it isn’t the CORE bot:</li>
|
||
</ul>
|
||
|
||
<pre><code># awk '{print $1}' /var/log/nginx/access.log | sort -n | uniq -c | sort -h | tail
|
||
306 68.180.229.31
|
||
323 61.148.244.116
|
||
414 66.249.66.91
|
||
507 40.77.167.16
|
||
618 157.55.39.161
|
||
652 207.46.13.103
|
||
666 157.55.39.254
|
||
1173 104.196.152.243
|
||
1737 66.249.66.90
|
||
23101 138.201.52.218
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>138.201.52.218 is from some Hetzner server, and I see it making 40,000 requests yesterday too, but none before that:</li>
|
||
</ul>
|
||
|
||
<pre><code># zgrep -c 138.201.52.218 /var/log/nginx/access.log*
|
||
/var/log/nginx/access.log:24403
|
||
/var/log/nginx/access.log.1:45958
|
||
/var/log/nginx/access.log.2.gz:0
|
||
/var/log/nginx/access.log.3.gz:0
|
||
/var/log/nginx/access.log.4.gz:0
|
||
/var/log/nginx/access.log.5.gz:0
|
||
/var/log/nginx/access.log.6.gz:0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>It’s clearly a bot as it’s making tens of thousands of requests, but it’s using a “normal” user agent:</li>
|
||
</ul>
|
||
|
||
<pre><code>Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.0 Safari/537.36
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>For now I don’t know what this user is!</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-05">2017-11-05</h2>
|
||
|
||
<ul>
|
||
<li>Peter asked if I could fix the appearance of “International Livestock Research Institute” in the author lookup during item submission</li>
|
||
<li>It looks to be just an issue with the user interface expecting authors to have both a first and last name:</li>
|
||
</ul>
|
||
|
||
<p><img src="/cgspace-notes/2017/11/author-lookup.png" alt="Author lookup" />
|
||
<img src="/cgspace-notes/2017/11/add-author.png" alt="Add author" /></p>
|
||
|
||
<ul>
|
||
<li>But in the database the authors are correct (none with weird <code>, /</code> characters):</li>
|
||
</ul>
|
||
|
||
<pre><code>dspace=# select distinct text_value, authority, confidence from metadatavalue value where resource_type_id=2 and metadata_field_id=3 and text_value like 'International Livestock Research Institute%';
|
||
text_value | authority | confidence
|
||
--------------------------------------------+--------------------------------------+------------
|
||
International Livestock Research Institute | 8f3865dc-d056-4aec-90b7-77f49ab4735c | 0
|
||
International Livestock Research Institute | f4db1627-47cd-4699-b394-bab7eba6dadc | 0
|
||
International Livestock Research Institute | | -1
|
||
International Livestock Research Institute | 8f3865dc-d056-4aec-90b7-77f49ab4735c | 600
|
||
International Livestock Research Institute | f4db1627-47cd-4699-b394-bab7eba6dadc | -1
|
||
International Livestock Research Institute | | 600
|
||
International Livestock Research Institute | 8f3865dc-d056-4aec-90b7-77f49ab4735c | -1
|
||
International Livestock Research Institute | 8f3865dc-d056-4aec-90b7-77f49ab4735c | 500
|
||
(8 rows)
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>So I’m not sure if this is just a graphical glitch or if editors have to edit this metadata field prior to approval</li>
|
||
<li>Looking at monitoring Tomcat’s JVM heap with Prometheus, it looks like we need to use JMX + <a href="https://github.com/prometheus/jmx_exporter">jmx_exporter</a></li>
|
||
<li>This guide shows how to <a href="https://geekflare.com/enable-jmx-tomcat-to-monitor-administer/">enable JMX in Tomcat</a> by modifying <code>CATALINA_OPTS</code></li>
|
||
<li>I was able to successfully connect to my local Tomcat with jconsole!</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-07">2017-11-07</h2>
|
||
|
||
<ul>
|
||
<li>CGSpace when down and up a few times this morning, first around 3AM, then around 7</li>
|
||
<li>Tsega had to restart Tomcat 7 to fix it temporarily</li>
|
||
<li>I will start by looking at bot usage (access.log.1 includes usage until 6AM today):</li>
|
||
</ul>
|
||
|
||
<pre><code># cat /var/log/nginx/access.log.1 | awk '{print $1}' | sort -n | uniq -c | sort -h | tail
|
||
619 65.49.68.184
|
||
840 65.49.68.199
|
||
924 66.249.66.91
|
||
1131 68.180.229.254
|
||
1583 66.249.66.90
|
||
1953 207.46.13.103
|
||
1999 207.46.13.80
|
||
2021 157.55.39.161
|
||
2034 207.46.13.36
|
||
4681 104.196.152.243
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>104.196.152.243 seems to be a top scraper for a few weeks now:</li>
|
||
</ul>
|
||
|
||
<pre><code># zgrep -c 104.196.152.243 /var/log/nginx/access.log*
|
||
/var/log/nginx/access.log:336
|
||
/var/log/nginx/access.log.1:4681
|
||
/var/log/nginx/access.log.2.gz:3531
|
||
/var/log/nginx/access.log.3.gz:3532
|
||
/var/log/nginx/access.log.4.gz:5786
|
||
/var/log/nginx/access.log.5.gz:8542
|
||
/var/log/nginx/access.log.6.gz:6988
|
||
/var/log/nginx/access.log.7.gz:7517
|
||
/var/log/nginx/access.log.8.gz:7211
|
||
/var/log/nginx/access.log.9.gz:2763
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>This user is responsible for hundreds and sometimes thousands of Tomcat sessions:</li>
|
||
</ul>
|
||
|
||
<pre><code>$ grep 104.196.152.243 dspace.log.2017-11-07 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
954
|
||
$ grep 104.196.152.243 dspace.log.2017-11-03 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
6199
|
||
$ grep 104.196.152.243 dspace.log.2017-11-01 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
7051
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The worst thing is that this user never specifies a user agent string so we can’t lump it in with the other bots using the Tomcat Session Crawler Manager Valve</li>
|
||
<li>They don’t request dynamic URLs like “/discover” but they seem to be fetching handles from XMLUI instead of REST (and some with <code>//handle</code>, note the regex below):</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c 104.196.152.243 /var/log/nginx/access.log.1
|
||
4681
|
||
# grep 104.196.152.243 /var/log/nginx/access.log.1 | grep -c -P 'GET //?handle'
|
||
4618
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>I just realized that <code>ciat.cgiar.org</code> points to 104.196.152.243, so I should contact Leroy from CIAT to see if we can change their scraping behavior</li>
|
||
<li>The next IP (207.46.13.36) seem to be Microsoft’s bingbot, but all its requests specify the “bingbot” user agent and there are no requests for dynamic URLs that are forbidden, like “/discover”:</li>
|
||
</ul>
|
||
|
||
<pre><code>$ grep -c 207.46.13.36 /var/log/nginx/access.log.1
|
||
2034
|
||
# grep 207.46.13.36 /var/log/nginx/access.log.1 | grep -c "GET /discover"
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The next IP (157.55.39.161) also seems to be bingbot, and none of its requests are for URLs forbidden by robots.txt either:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep 157.55.39.161 /var/log/nginx/access.log.1 | grep -c "GET /discover"
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The next few seem to be bingbot as well, and they declare a proper user agent and do not request dynamic URLs like “/discover”:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c -E '207.46.13.[0-9]{2,3}' /var/log/nginx/access.log.1
|
||
5997
|
||
# grep -E '207.46.13.[0-9]{2,3}' /var/log/nginx/access.log.1 | grep -c "bingbot"
|
||
5988
|
||
# grep -E '207.46.13.[0-9]{2,3}' /var/log/nginx/access.log.1 | grep -c "GET /discover"
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The next few seem to be Googlebot, and they declare a proper user agent and do not request dynamic URLs like “/discover”:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c -E '66.249.66.[0-9]{2,3}' /var/log/nginx/access.log.1
|
||
3048
|
||
# grep -E '66.249.66.[0-9]{2,3}' /var/log/nginx/access.log.1 | grep -c Google
|
||
3048
|
||
# grep -E '66.249.66.[0-9]{2,3}' /var/log/nginx/access.log.1 | grep -c "GET /discover"
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The next seems to be Yahoo, which declares a proper user agent and does not request dynamic URLs like “/discover”:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c 68.180.229.254 /var/log/nginx/access.log.1
|
||
1131
|
||
# grep 68.180.229.254 /var/log/nginx/access.log.1 | grep -c "GET /discover"
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The last of the top ten IPs seems to be some bot with a weird user agent, but they are not behaving too well:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c -E '65.49.68.[0-9]{3}' /var/log/nginx/access.log.1
|
||
2950
|
||
# grep -E '65.49.68.[0-9]{3}' /var/log/nginx/access.log.1 | grep -c "GET /discover"
|
||
330
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Their user agents vary, ie:
|
||
|
||
<ul>
|
||
<li><code>Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36</code></li>
|
||
<li><code>Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11</code></li>
|
||
<li><code>Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)</code></li>
|
||
</ul></li>
|
||
<li>I’ll just keep an eye on that one for now, as it only made a few hundred requests to dynamic discovery URLs</li>
|
||
<li>While it’s not in the top ten, Baidu is one bot that seems to not give a fuck:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c Baiduspider /var/log/nginx/access.log.1
|
||
8068
|
||
# grep Baiduspider /var/log/nginx/access.log.1 | grep -c -E "GET /(browse|discover)"
|
||
1431
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>According to their documentation their bot <a href="http://www.baidu.com/search/robots_english.html">respects <code>robots.txt</code></a>, but I don’t see this being the case</li>
|
||
<li>I think I will end up blocking Baidu as well…</li>
|
||
<li>Next is for me to look and see what was happening specifically at 3AM and 7AM when the server crashed</li>
|
||
<li>I should look in nginx access.log, rest.log, oai.log, and DSpace’s dspace.log.2017-11-07</li>
|
||
<li>Here are the top IPs making requests to XMLUI from 2 to 8 AM:</li>
|
||
</ul>
|
||
|
||
<pre><code># cat /var/log/nginx/access.log /var/log/nginx/access.log.1 | grep -E '07/Nov/2017:0[2-8]' | awk '{print $1}' | sort -n | uniq -c | sort -h | tail
|
||
279 66.249.66.91
|
||
373 65.49.68.199
|
||
446 68.180.229.254
|
||
470 104.196.152.243
|
||
470 197.210.168.174
|
||
598 207.46.13.103
|
||
603 157.55.39.161
|
||
637 207.46.13.80
|
||
703 207.46.13.36
|
||
724 66.249.66.90
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Of those, most are Google, Bing, Yahoo, etc, except 63.143.42.244 and 63.143.42.242 which are Uptime Robot</li>
|
||
<li>Here are the top IPs making requests to REST from 2 to 8 AM:</li>
|
||
</ul>
|
||
|
||
<pre><code># cat /var/log/nginx/rest.log /var/log/nginx/rest.log.1 | grep -E '07/Nov/2017:0[2-8]' | awk '{print $1}' | sort -n | uniq -c | sort -h | tail
|
||
8 207.241.229.237
|
||
10 66.249.66.90
|
||
16 104.196.152.243
|
||
25 41.60.238.61
|
||
26 157.55.39.161
|
||
27 207.46.13.103
|
||
27 207.46.13.80
|
||
31 207.46.13.36
|
||
1498 50.116.102.77
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The OAI requests during that same time period are nothing to worry about:</li>
|
||
</ul>
|
||
|
||
<pre><code># cat /var/log/nginx/oai.log /var/log/nginx/oai.log.1 | grep -E '07/Nov/2017:0[2-8]' | awk '{print $1}' | sort -n | uniq -c | sort -h | tail
|
||
1 66.249.66.92
|
||
4 66.249.66.90
|
||
6 68.180.229.254
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The top IPs from dspace.log during the 2–8 AM period:</li>
|
||
</ul>
|
||
|
||
<pre><code>$ grep -E '2017-11-07 0[2-8]' dspace.log.2017-11-07 | grep -o -E 'ip_addr=[0-9.]+' | sort -n | uniq -c | sort -h | tail
|
||
143 ip_addr=213.55.99.121
|
||
181 ip_addr=66.249.66.91
|
||
223 ip_addr=157.55.39.161
|
||
248 ip_addr=207.46.13.80
|
||
251 ip_addr=207.46.13.103
|
||
291 ip_addr=207.46.13.36
|
||
297 ip_addr=197.210.168.174
|
||
312 ip_addr=65.49.68.199
|
||
462 ip_addr=104.196.152.243
|
||
488 ip_addr=66.249.66.90
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>These aren’t actually very interesting, as the top few are Google, CIAT, Bingbot, and a few other unknown scrapers</li>
|
||
<li>The number of requests isn’t even that high to be honest</li>
|
||
<li>As I was looking at these logs I noticed another heavy user (124.17.34.59) that was not active during this time period, but made many requests today alone:</li>
|
||
</ul>
|
||
|
||
<pre><code># zgrep -c 124.17.34.59 /var/log/nginx/access.log*
|
||
/var/log/nginx/access.log:22581
|
||
/var/log/nginx/access.log.1:0
|
||
/var/log/nginx/access.log.2.gz:14
|
||
/var/log/nginx/access.log.3.gz:0
|
||
/var/log/nginx/access.log.4.gz:0
|
||
/var/log/nginx/access.log.5.gz:3
|
||
/var/log/nginx/access.log.6.gz:0
|
||
/var/log/nginx/access.log.7.gz:0
|
||
/var/log/nginx/access.log.8.gz:0
|
||
/var/log/nginx/access.log.9.gz:1
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The whois data shows the IP is from China, but the user agent doesn’t really give any clues:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep 124.17.34.59 /var/log/nginx/access.log | awk -F'" ' '{print $3}' | sort | uniq -c | sort -h
|
||
210 "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"
|
||
22610 "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.2; Win64; x64; Trident/7.0; LCTE)"
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>A Google search for “LCTE bot” doesn’t return anything interesting, but this <a href="https://stackoverflow.com/questions/42500881/what-is-lcte-in-user-agent">Stack Overflow discussion</a> references the lack of information</li>
|
||
<li>So basically after a few hours of looking at the log files I am not closer to understanding what is going on!</li>
|
||
<li>I do know that we want to block Baidu, though, as it does not respect <code>robots.txt</code></li>
|
||
<li>And as we speak Linode alerted that the outbound traffic rate is very high for the past two hours (about 12–14 hours)</li>
|
||
<li>At least for now it seems to be that new Chinese IP (124.17.34.59):</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -E "07/Nov/2017:1[234]:" /var/log/nginx/access.log | awk '{print $1}' | sort -n | uniq -c | sort -h | tail
|
||
198 207.46.13.103
|
||
203 207.46.13.80
|
||
205 207.46.13.36
|
||
218 157.55.39.161
|
||
249 45.5.184.221
|
||
258 45.5.187.130
|
||
386 66.249.66.90
|
||
410 197.210.168.174
|
||
1896 104.196.152.243
|
||
11005 124.17.34.59
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Seems 124.17.34.59 are really downloading all our PDFs, compared to the next top active IPs during this time!</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -E "07/Nov/2017:1[234]:" /var/log/nginx/access.log | grep 124.17.34.59 | grep -c pdf
|
||
5948
|
||
# grep -E "07/Nov/2017:1[234]:" /var/log/nginx/access.log | grep 104.196.152.243 | grep -c pdf
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>About CIAT, I think I need to encourage them to specify a user agent string for their requests, because they are not reuising their Tomcat session and they are creating thousands of sessions per day</li>
|
||
<li>All CIAT requests vs unique ones:</li>
|
||
</ul>
|
||
|
||
<pre><code>$ grep -Io -E 'session_id=[A-Z0-9]{32}:ip_addr=104.196.152.243' dspace.log.2017-11-07 | wc -l
|
||
3506
|
||
$ grep -Io -E 'session_id=[A-Z0-9]{32}:ip_addr=104.196.152.243' dspace.log.2017-11-07 | sort | uniq | wc -l
|
||
3506
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>I emailed CIAT about the session issue, user agent issue, and told them they should not scrape the HTML contents of communities, instead using the REST API</li>
|
||
<li>About Baidu, I found a link to their <a href="http://ziyuan.baidu.com/robots/">robots.txt tester tool</a></li>
|
||
<li>It seems like our robots.txt file is valid, and they claim to recognize that URLs like <code>/discover</code> should be forbidden (不允许, aka “not allowed”):</li>
|
||
</ul>
|
||
|
||
<p><img src="/cgspace-notes/2017/11/baidu-robotstxt.png" alt="Baidu robots.txt tester" /></p>
|
||
|
||
<ul>
|
||
<li>But they literally just made this request today:</li>
|
||
</ul>
|
||
|
||
<pre><code>180.76.15.136 - - [07/Nov/2017:06:25:11 +0000] "GET /discover?filtertype_0=crpsubject&filter_relational_operator_0=equals&filter_0=WATER%2C+LAND+AND+ECOSYSTEMS&filtertype=subject&filter_relational_operator=equals&filter=WATER+RESOURCES HTTP/1.1" 200 82265 "-" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Along with another thousand or so requests to URLs that are forbidden in robots.txt today alone:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep -c Baiduspider /var/log/nginx/access.log
|
||
3806
|
||
# grep Baiduspider /var/log/nginx/access.log | grep -c -E "GET /(browse|discover|search-filter)"
|
||
1085
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>I will think about blocking their IPs but they have 164 of them!</li>
|
||
</ul>
|
||
|
||
<pre><code># grep "Baiduspider/2.0" /var/log/nginx/access.log | awk '{print $1}' | sort -n | uniq | wc -l
|
||
164
|
||
</code></pre>
|
||
|
||
<h2 id="2017-11-08">2017-11-08</h2>
|
||
|
||
<ul>
|
||
<li>Linode sent several alerts last night about CPU usage and outbound traffic rate at 6:13PM</li>
|
||
<li>Linode sent another alert about CPU usage in the morning at 6:12AM</li>
|
||
<li>Jesus, the new Chinese IP (124.17.34.59) has downloaded 24,000 PDFs in the last 24 hours:</li>
|
||
</ul>
|
||
|
||
<pre><code># cat /var/log/nginx/access.log /var/log/nginx/access.log.1 | grep -E "0[78]/Nov/2017:" | grep 124.17.34.59 | grep -v pdf.jpg | grep -c pdf
|
||
24981
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>This is about 20,000 Tomcat sessions:</li>
|
||
</ul>
|
||
|
||
<pre><code>$ cat dspace.log.2017-11-07 dspace.log.2017-11-08 | grep -Io -E 'session_id=[A-Z0-9]{32}:ip_addr=124.17.34.59' | sort | uniq | wc -l
|
||
20733
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>I’m getting really sick of this</li>
|
||
<li>Sisay re-uploaded the CIAT records that I had already corrected earlier this week, erasing all my corrections</li>
|
||
<li>I had to re-correct all the publishers, places, names, dates, etc and apply the changes on DSpace Test</li>
|
||
<li>Run system updates on DSpace Test and reboot the server</li>
|
||
<li>Magdalena had written to say that two of their Phase II project tags were missing on CGSpace, so I added them (<a href="https://github.com/ilri/DSpace/pull/346">#346</a>)</li>
|
||
<li>I figured out a way to use nginx’s map function to assign a “bot” user agent to misbehaving clients who don’t define a user agent</li>
|
||
<li>Most bots are automatically lumped into one generic session by <a href="https://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Crawler_Session_Manager_Valve">Tomcat’s Crawler Session Manager Valve</a> but this only works if their user agent matches a pre-defined regular expression like <code>.*[bB]ot.*</code></li>
|
||
<li>Some clients send thousands of requests without a user agent which ends up creating thousands of Tomcat sessions, wasting precious memory, CPU, and database resources in the process</li>
|
||
<li>Basically, we modify the nginx config to add a mapping with a modified user agent <code>$ua</code>:</li>
|
||
</ul>
|
||
|
||
<pre><code>map $remote_addr $ua {
|
||
# 2017-11-08 Random Chinese host grabbing 20,000 PDFs
|
||
124.17.34.59 'ChineseBot';
|
||
default $http_user_agent;
|
||
}
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>If the client’s address matches then the user agent is set, otherwise the default <code>$http_user_agent</code> variable is used</li>
|
||
<li>Then, in the server’s <code>/</code> block we pass this header to Tomcat:</li>
|
||
</ul>
|
||
|
||
<pre><code>proxy_pass http://tomcat_http;
|
||
proxy_set_header User-Agent $ua;
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Note to self: the <code>$ua</code> variable won’t show up in nginx access logs because the default <code>combined</code> log format doesn’t show it, so don’t run around pulling your hair out wondering with the modified user agents aren’t showing in the logs!</li>
|
||
<li>If a client matching one of these IPs connects without a session, it will be assigned one by the Crawler Session Manager Valve</li>
|
||
<li>You can verify by cross referencing nginx’s <code>access.log</code> and DSpace’s <code>dspace.log.2017-11-08</code>, for example</li>
|
||
<li>I will deploy this on CGSpace later this week</li>
|
||
<li>I am interested to check how this affects the number of sessions used by the CIAT and Chinese bots (see above on <a href="#2017-11-07">2017-11-07</a> for example)</li>
|
||
<li>I merged the clickable thumbnails code to <code>5_x-prod</code> (<a href="https://github.com/ilri/DSpace/pull/347">#347</a>) and will deploy it later along with the new bot mapping stuff (and re-run the Asible <code>nginx</code> and <code>tomcat</code> tags)</li>
|
||
<li>I was thinking about Baidu again and decided to see how many requests they have versus Google to URL paths that are explicitly forbidden in <code>robots.txt</code>:</li>
|
||
</ul>
|
||
|
||
<pre><code># zgrep Baiduspider /var/log/nginx/access.log* | grep -c -E "GET /(browse|discover|search-filter)"
|
||
22229
|
||
# zgrep Googlebot /var/log/nginx/access.log* | grep -c -E "GET /(browse|discover|search-filter)"
|
||
0
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>It seems that they rarely even bother checking <code>robots.txt</code>, but Google does multiple times per day!</li>
|
||
</ul>
|
||
|
||
<pre><code># zgrep Baiduspider /var/log/nginx/access.log* | grep -c robots.txt
|
||
14
|
||
# zgrep Googlebot /var/log/nginx/access.log* | grep -c robots.txt
|
||
1134
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>I have been looking for a reason to ban Baidu and this is definitely a good one</li>
|
||
<li>Disallowing <code>Baiduspider</code> in <code>robots.txt</code> probably won’t work because this bot doesn’t seem to respect the robot exclusion standard anyways!</li>
|
||
<li>I will whip up something in nginx later</li>
|
||
<li>Run system updates on CGSpace and reboot the server</li>
|
||
<li>Re-deploy latest <code>5_x-prod</code> branch on CGSpace and DSpace Test (includes the clickable thumbnails, CCAFS phase II project tags, and updated news text)</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-09">2017-11-09</h2>
|
||
|
||
<ul>
|
||
<li>Awesome, it seems my bot mapping stuff in nginx actually reduced the number of Tomcat sessions used by the CIAT scraper today, total requests and unique sessions:</li>
|
||
</ul>
|
||
|
||
<pre><code># zcat -f -- /var/log/nginx/access.log.1 /var/log/nginx/access.log.2.gz | grep '09/Nov/2017' | grep -c 104.196.152.243
|
||
8956
|
||
$ grep 104.196.152.243 dspace.log.2017-11-09 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
223
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Versus the same stats for yesterday and the day before:</li>
|
||
</ul>
|
||
|
||
<pre><code># zcat -f -- /var/log/nginx/access.log.1 /var/log/nginx/access.log.2.gz | grep '08/Nov/2017' | grep -c 104.196.152.243
|
||
10216
|
||
$ grep 104.196.152.243 dspace.log.2017-11-08 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
2592
|
||
# zcat -f -- /var/log/nginx/access.log.2.gz /var/log/nginx/access.log.3.gz | grep '07/Nov/2017' | grep -c 104.196.152.243
|
||
8120
|
||
$ grep 104.196.152.243 dspace.log.2017-11-07 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
3506
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>The number of sessions is over <em>ten times less</em>!</li>
|
||
<li>This gets me thinking, I wonder if I can use something like nginx’s rate limiter to automatically change the user agent of clients who make too many requests</li>
|
||
<li>Perhaps using a combination of geo and map, like illustrated here: <a href="https://www.nginx.com/blog/rate-limiting-nginx/">https://www.nginx.com/blog/rate-limiting-nginx/</a></li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-11">2017-11-11</h2>
|
||
|
||
<ul>
|
||
<li>I was looking at the Google index and noticed there are 4,090 search results for dspace.ilri.org but only seven for mahider.ilri.org</li>
|
||
<li>Search with something like: inurl:dspace.ilri.org inurl:https</li>
|
||
<li>I want to get rid of those legacy domains eventually!</li>
|
||
</ul>
|
||
|
||
<h2 id="2017-11-12">2017-11-12</h2>
|
||
|
||
<ul>
|
||
<li>Update the <a href="https://github.com/ilri/rmg-ansible-public">Ansible infrastructure templates</a> to be a little more modular and flexible</li>
|
||
<li>Looking at the top client IPs on CGSpace so far this morning, even though it’s only been eight hours:</li>
|
||
</ul>
|
||
|
||
<pre><code># cat /var/log/nginx/access.log /var/log/nginx/access.log.1 | grep "12/Nov/2017" | awk '{print $1}' | sort -n | uniq -c | sort -h | tail
|
||
243 5.83.120.111
|
||
335 40.77.167.103
|
||
424 66.249.66.91
|
||
529 207.46.13.36
|
||
554 40.77.167.129
|
||
604 207.46.13.53
|
||
754 104.196.152.243
|
||
883 66.249.66.90
|
||
1150 95.108.181.88
|
||
1381 5.9.6.51
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>5.9.6.51 seems to be a Russian bot:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep 5.9.6.51 /var/log/nginx/access.log | tail -n 1
|
||
5.9.6.51 - - [12/Nov/2017:08:13:13 +0000] "GET /handle/10568/16515/recent-submissions HTTP/1.1" 200 5097 "-" "Mozilla/5.0 (compatible; MegaIndex.ru/2.0; +http://megaindex.com/crawler)"
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>What’s amazing is that it seems to reuse its Java session across all requests:</li>
|
||
</ul>
|
||
|
||
<pre><code>$ grep -c -E 'session_id=[A-Z0-9]{32}:ip_addr=5.9.6.51' /home/cgspace.cgiar.org/log/dspace.log.2017-11-12
|
||
1558
|
||
$ grep 5.9.6.51 /home/cgspace.cgiar.org/log/dspace.log.2017-11-12 | grep -o -E 'session_id=[A-Z0-9]{32}' | sort -n | uniq | wc -l
|
||
1
|
||
</code></pre>
|
||
|
||
<ul>
|
||
<li>Bravo to MegaIndex.ru!</li>
|
||
<li>The same cannot be said for 95.108.181.88, which appears to be YandexBot, even though Tomcat’s Crawler Session Manager valve regex should match ‘YandexBot’:</li>
|
||
</ul>
|
||
|
||
<pre><code># grep 95.108.181.88 /var/log/nginx/access.log | tail -n 1
|
||
95.108.181.88 - - [12/Nov/2017:08:33:17 +0000] "GET /bitstream/handle/10568/57004/GenebankColombia_23Feb2015.pdf HTTP/1.1" 200 972019 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
|
||
$ grep -c -E 'session_id=[A-Z0-9]{32}:ip_addr=95.108.181.88' /home/cgspace.cgiar.org/log/dspace.log.2017-11-12
|
||
991
|
||
</code></pre>
|
||
|
||
|
||
|
||
|
||
|
||
</article>
|
||
|
||
|
||
|
||
</div> <!-- /.blog-main -->
|
||
|
||
<aside class="col-sm-3 ml-auto blog-sidebar">
|
||
|
||
|
||
|
||
<section class="sidebar-module">
|
||
<h4>Recent Posts</h4>
|
||
<ol class="list-unstyled">
|
||
|
||
|
||
<li><a href="/cgspace-notes/2017-11/">November, 2017</a></li>
|
||
|
||
<li><a href="/cgspace-notes/2017-10/">October, 2017</a></li>
|
||
|
||
<li><a href="/cgspace-notes/cgiar-library-migration/">CGIAR Library Migration</a></li>
|
||
|
||
<li><a href="/cgspace-notes/2017-09/">September, 2017</a></li>
|
||
|
||
<li><a href="/cgspace-notes/2017-08/">August, 2017</a></li>
|
||
|
||
</ol>
|
||
</section>
|
||
|
||
|
||
|
||
|
||
<section class="sidebar-module">
|
||
<h4>Links</h4>
|
||
<ol class="list-unstyled">
|
||
|
||
<li><a href="https://cgspace.cgiar.org">CGSpace</a></li>
|
||
|
||
<li><a href="https://dspacetest.cgiar.org">DSpace Test</a></li>
|
||
|
||
<li><a href="https://github.com/ilri/DSpace">CGSpace @ GitHub</a></li>
|
||
|
||
</ol>
|
||
</section>
|
||
|
||
</aside>
|
||
|
||
|
||
</div> <!-- /.row -->
|
||
</div> <!-- /.container -->
|
||
|
||
<footer class="blog-footer">
|
||
<p>
|
||
|
||
Blog template created by <a href="https://twitter.com/mdo">@mdo</a>, ported to Hugo by <a href='https://twitter.com/mralanorth'>@mralanorth</a>.
|
||
|
||
</p>
|
||
<p>
|
||
<a href="#">Back to top</a>
|
||
</p>
|
||
</footer>
|
||
|
||
</body>
|
||
|
||
</html>
|