Update notes for 2018-06-24

This commit is contained in:
Alan Orth 2018-06-24 13:37:43 +03:00
parent ccec3f2e4f
commit a3c64ba829
Signed by: alanorth
GPG Key ID: 0FB860CC9C45B1B9
4 changed files with 32 additions and 14 deletions

View File

@ -242,5 +242,14 @@ $ psql -h localhost -U postgres dspacetest -c 'alter user dspacetest nosuperuser
- The `-O` option to `pg_restore` makes the import process ignore ownership specified in the dump itself, and instead makes the schema owned by the user doing the restore
- I always prefer to use the `postgres` user locally because it's just easier than remembering the `dspacetest` user's password, but then I couldn't figure out why the resulting schema was owned by `postgres`
- So with this you connect as the `postgres` superuser and then switch roles to `dspacetest` (also, make sure this user has `superuser` privileges before the restore)
- Last week Linode emailed me to say that our Linode 8192 instance used for DSpace Test qualified for an upgrade
- Apparently they announced some [upgrades to most of their plans in 2018-05](https://blog.linode.com/2018/05/17/updated-linode-plans-new-larger-linodes/)
- After the upgrade I see we have more disk space available in the instance's dashboard, so I shut the instance down and resized it from 98GB to 160GB
- The resize was very quick (less than one minute) and after booting the instance back up I now have 160GB for the root filesystem!
- I will move the DSpace installation directory back to the root file system and delete the extra 300GB block storage, as it was actually kinda slow when we put Solr there and now we don't actually need it anymore because running the production Solr on this instance didn't work well with 8GB of RAM
- Also, the larger instance we're using for CGSpace will go from 24GB of RAM to 32, and will also get a storage increase from 320GB to 640GB... that means we don't need to consider using block storage right now!
- The smaller instances get increased storage and network speed but I doubt many are actually using much of their current allocations so we probably don't need to bother with upgrading them
- Last week Abenet asked if we could add `dc.language.iso` to the advanced search filters
- There is already a search filter for this field defined in `discovery.xml` but we aren't using it, so I quickly enabled and tested it, then merged it to the `5_x-prod` branch ([#380](https://github.com/ilri/DSpace/pull/380))
<!-- vim: set sw=2 ts=2: -->

View File

@ -41,7 +41,7 @@ sys 2m7.289s
<meta property="article:published_time" content="2018-06-04T19:49:54-07:00"/>
<meta property="article:modified_time" content="2018-06-14T14:46:09&#43;03:00"/>
<meta property="article:modified_time" content="2018-06-24T09:41:33&#43;03:00"/>
@ -93,9 +93,9 @@ sys 2m7.289s
"@type": "BlogPosting",
"headline": "June, 2018",
"url": "https://alanorth.github.io/cgspace-notes/2018-06/",
"wordCount": "1814",
"wordCount": "2068",
"datePublished": "2018-06-04T19:49:54-07:00",
"dateModified": "2018-06-14T14:46:09&#43;03:00",
"dateModified": "2018-06-24T09:41:33&#43;03:00",
"author": {
"@type": "Person",
"name": "Alan Orth"
@ -444,6 +444,15 @@ $ psql -h localhost -U postgres dspacetest -c 'alter user dspacetest nosuperuser
<li>The <code>-O</code> option to <code>pg_restore</code> makes the import process ignore ownership specified in the dump itself, and instead makes the schema owned by the user doing the restore</li>
<li>I always prefer to use the <code>postgres</code> user locally because it&rsquo;s just easier than remembering the <code>dspacetest</code> user&rsquo;s password, but then I couldn&rsquo;t figure out why the resulting schema was owned by <code>postgres</code></li>
<li>So with this you connect as the <code>postgres</code> superuser and then switch roles to <code>dspacetest</code> (also, make sure this user has <code>superuser</code> privileges before the restore)</li>
<li>Last week Linode emailed me to say that our Linode 8192 instance used for DSpace Test qualified for an upgrade</li>
<li>Apparently they announced some <a href="https://blog.linode.com/2018/05/17/updated-linode-plans-new-larger-linodes/">upgrades to most of their plans in 2018-05</a></li>
<li>After the upgrade I see we have more disk space available in the instance&rsquo;s dashboard, so I shut the instance down and resized it from 98GB to 160GB</li>
<li>The resize was very quick (less than one minute) and after booting the instance back up I now have 160GB for the root filesystem!</li>
<li>I will move the DSpace installation directory back to the root file system and delete the extra 300GB block storage, as it was actually kinda slow when we put Solr there and now we don&rsquo;t actually need it anymore because running the production Solr on this instance didn&rsquo;t work well with 8GB of RAM</li>
<li>Also, the larger instance we&rsquo;re using for CGSpace will go from 24GB of RAM to 32, and will also get a storage increase from 320GB to 640GB&hellip; that means we don&rsquo;t need to consider using block storage right now!</li>
<li>The smaller instances get increased storage and network speed but I doubt many are actually using much of their current allocations so we probably don&rsquo;t need to bother with upgrading them</li>
<li>Last week Abenet asked if we could add <code>dc.language.iso</code> to the advanced search filters</li>
<li>There is already a search filter for this field defined in <code>discovery.xml</code> but we aren&rsquo;t using it, so I quickly enabled and tested it, then merged it to the <code>5_x-prod</code> branch (<a href="https://github.com/ilri/DSpace/pull/380">#380</a>)</li>
</ul>
<!-- vim: set sw=2 ts=2: -->

View File

@ -36,7 +36,7 @@ Disallow: /cgspace-notes/2015-12/
Disallow: /cgspace-notes/2015-11/
Disallow: /cgspace-notes/
Disallow: /cgspace-notes/categories/
Disallow: /cgspace-notes/categories/notes/
Disallow: /cgspace-notes/tags/notes/
Disallow: /cgspace-notes/categories/notes/
Disallow: /cgspace-notes/posts/
Disallow: /cgspace-notes/tags/

View File

@ -4,7 +4,7 @@
<url>
<loc>https://alanorth.github.io/cgspace-notes/2018-06/</loc>
<lastmod>2018-06-14T14:46:09+03:00</lastmod>
<lastmod>2018-06-24T09:41:33+03:00</lastmod>
</url>
<url>
@ -169,7 +169,7 @@
<url>
<loc>https://alanorth.github.io/cgspace-notes/</loc>
<lastmod>2018-06-14T14:46:09+03:00</lastmod>
<lastmod>2018-06-24T09:41:33+03:00</lastmod>
<priority>0</priority>
</url>
@ -178,27 +178,27 @@
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/tags/notes/</loc>
<lastmod>2018-06-24T09:41:33+03:00</lastmod>
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/categories/notes/</loc>
<lastmod>2018-03-09T22:10:33+02:00</lastmod>
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/tags/notes/</loc>
<lastmod>2018-06-14T14:46:09+03:00</lastmod>
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/posts/</loc>
<lastmod>2018-06-14T14:46:09+03:00</lastmod>
<lastmod>2018-06-24T09:41:33+03:00</lastmod>
<priority>0</priority>
</url>
<url>
<loc>https://alanorth.github.io/cgspace-notes/tags/</loc>
<lastmod>2018-06-14T14:46:09+03:00</lastmod>
<lastmod>2018-06-24T09:41:33+03:00</lastmod>
<priority>0</priority>
</url>