CGSpace Notes

Documenting day-to-day work on the CGSpace repository.

August, 2019

2019-08-03

  • Look at Bioversity’s latest migration CSV and now I see that Francesco has cleaned up the extra columns and the newline at the end of the file, but many of the column headers have an extra space in the name…

2019-08-04

  • Deploy ORCID identifier updates requested by Bioversity to CGSpace
  • Run system updates on CGSpace (linode18) and reboot it
    • Before updating it I checked Solr and verified that all statistics cores were loaded properly…
    • After rebooting, all statistics cores were loaded… wow, that’s lucky.
  • Run system updates on DSpace Test (linode19) and reboot it

2019-08-05

2019-08-06

  • Francesca responded to address my feedback yesterday
    • I made some changes to the CSV based on her feedback (remove two duplicates, change one PDF file name, change two titles)
    • Then I found some items that have PDFs in multiple languages that only list one language in dc.language.iso so I changed them
    • Strangley, one item was referring to a 7zip file…
    • After removing the two duplicates there are now 1427 records
    • Fix one invalid ISSN: 1020-2002→1020-3362

2019-08-07

  • Daniel Haile-Michael asked about using a logical OR with the DSpace OpenSearch, but I looked in the DSpace manual and it does not seem to be possible

2019-08-08

  • Moayad noticed that the HTTPS certificate expired on the AReS dev server (linode20)

    • The first problem was that there is a Docker container listening on port 80, so it conflicts with the ACME http-01 validation
    • The second problem was that we only allow access to port 80 from localhost
    • I adjusted the renew-letsencrypt systemd service so it stops/starts the Docker container and firewall:

      # /opt/certbot-auto renew --standalone --pre-hook "/usr/bin/docker stop angular_nginx; /bin/systemctl stop firewalld" --post-hook "/bin/systemctl start firewalld; /usr/bin/docker start angular_nginx"
      
  • It is important that the firewall starts back up before the Docker container or else Docker will complain about missing iptables chains

  • Also, I updated to the latest TLS Intermediate settings as appropriate for Ubuntu 18.04’s OpenSSL 1.1.0g with nginx 1.16.0

  • Run all system updates on AReS dev server (linode20) and reboot it

  • Get a list of all PDFs from the Bioversity migration that fail to download and save them so I can try again with a different path in the URL:

    $ ./generate-thumbnails.py -i /tmp/2019-08-05-Bioversity-Migration.csv -w --url-field-name url -d | tee /tmp/2019-08-08-download-pdfs.txt
    $ grep -B1 "Download failed" /tmp/2019-08-08-download-pdfs.txt | grep "Downloading" | sed -e 's/> Downloading //' -e 's/\.\.\.//' | sed -r 's/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g' | csvcut -H -c 1,1 > /tmp/user-upload.csv
    $ ./generate-thumbnails.py -i /tmp/user-upload.csv -w --url-field-name url -d | tee /tmp/2019-08-08-download-pdfs2.txt
    $ grep -B1 "Download failed" /tmp/2019-08-08-download-pdfs2.txt | grep "Downloading" | sed -e 's/> Downloading //' -e 's/\.\.\.//' | sed -r 's/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[mGK]//g' | csvcut -H -c 1,1 > /tmp/user-upload2.csv
    $ ./generate-thumbnails.py -i /tmp/user-upload2.csv -w --url-field-name url -d | tee /tmp/2019-08-08-download-pdfs3.txt
    
  • (the weird sed regex removes color codes, because my generate-thumbnails script prints pretty colors)

  • Some PDFs are uploaded in different paths so I have to try a few times to get them all:

    • /fileadmin/_migrated/uploads/tx_news/
    • /fileadmin/user_upload/online_library/publications/pdfs/
    • /fileadmin/user_upload/
  • Even so, there are still 52 items with incorrect filenames, so I can’t derive their PDF URLs…

  • I will proceed with a metadata-only upload first and then let them know about the missing PDFs

  • Troubleshoot an issue we had with proxying to the new development version of AReS from DSpace Test (linode19)

    • For some reason the host header in the proxy pass is not set so nginx on DSpace Test makes a request to the upstream nginx on an IP-based virtual host
    • The upstream nginx returns HTTP 444 because we configured it to not answer when a request does not send a valid hostname
    • The solution is to set the host header when proxy passing:

      proxy_set_header Host dev.ares.codeobia.com;
      
  • Though I am really wondering why this happened now, because the configuration has been working for months…

  • Improve the output of the suspicious characters check in csv-metadata-quality script and tag version 0.2.0

2019-08-09

  • Looking at the 128 IITA records (20195TH.xls) that Sisay uploadd to DSpace Test last month: IITA_July_29
    • The records are pretty clean because Sisay ran them through the csv-metadata-quality tool
    • I fixed one incorrect country (MELBOURNE)
    • I normalized all DOIs to be https://doi.org format
    • This item is using the wrong Google Books link: https://dspacetest.cgiar.org/handle/10568/102593
    • The French abstract here has copy/paste errors: https://dspacetest.cgiar.org/handle/10568/102491
    • Validate and normalize affiliations against our 2019-04 list using reconcile-csv and OpenRefine:
    • $ lein run ~/src/git/DSpace/2019-04-08-affiliations.csv name id
    • I always forget how to copy the reconciled values in OpenRefine, but you need to make a new colum and populate it using this GREL: if(cell.recon.matched, cell.recon.match.name, value)
    • I asked Bosede to check about twenty-five invalid AGROVOC subjects identified by csv-metadata-quality script
    • I still need to check the sponsors and then check for duplicates

2019-08-10

  • Add checks for uncommon filename extensions and replacements for unneccesary Unicode to the csv-metadata-quality script

2019-08-12

2019-08-13

  • Create a test user on DSpace Test for Mohammad Salem to attempt depositing:

    $ dspace user -a -m blah@blah.com -g Mohammad -s Salem -p 'domoamaaa'
    
  • Create and merge a pull request (#429) to add eleven new CCAFS Phase II Project Tags to CGSpace

  • Atmire responded to the Solr cores issue last week, but they could not reproduce the issue

    • I told them not to continue, and that we would keep an eye on it and keep troubleshooting it (if neccessary) in the public eye on dspace-tech and Solr mailing lists
  • Testing an import of 1,429 Bioversity items (metadata only) on my local development machine and got an error with Java memory after about 1,000 items:

    $ ~/dspace/bin/dspace metadata-import -f /tmp/bioversity.csv -e blah@blah.com
    ...
    java.lang.OutOfMemoryError: GC overhead limit exceeded
    
  • I increased the heap size to 1536m and tried again:

    $ export JAVA_OPTS="-Dfile.encoding=UTF-8 -Xmx1536m"
    $ ~/dspace/bin/dspace metadata-import -f /tmp/bioversity.csv -e blah@blah.com
    
  • This time it succeeded, and using VisualVM I noticed that the import process used a maximum of 620MB of RAM

2019-08-14

  • I imported the 1429 Bioversity records into DSpace Test

    • To make sure we didn’t have memory issues I reduced Tomcat’s JVM heap by 512m, increased the import processes’s heap to 512m, and split the input file into two parts with about 700 each
    • Then I had to create a few new temporary collections on DSpace Test that had been created on CGSpace after our last sync
    • After that the import succeeded:

      $ export JAVA_OPTS='-Dfile.encoding=UTF-8 -Xmx512m'
      $ dspace metadata-import -f /tmp/bioversity1.csv -e blah@blah.com
      $ dspace metadata-import -f /tmp/bioversity2.csv -e blah@blah.com
      
  • The next step is to check these items for duplicates