Re: [dspace-tech] Issue with Two Dspace servers with common NAS for bitstore (assetstore)

[Ravi Konila]

Hi Raghwendra

Could you please elaborate on what you are suggesting. My postgres is already 
in HA and I do not have any problems with the db. 
If you are referring DB as Dspace Backend, it is already common to both the 
frontends. 

With Warm Regards
Ravi K.
Ph: +91-9901072688 


From: Raghwendra Narayan 
Sent: Monday, July 31, 2023 10:44 PM
To: Ravi Konila 
Cc: DSpace Technical Support 
Subject: Re: [dspace-tech] Issue with Two Dspace servers with common NAS for 
bitstore (assetstore)

Hi Ravi, 

U can use main DB to both front end.  It will work .  I am using similar 
configuration.

Regards.

On Mon, 31 Jul, 2023, 21:43 Ravi Konila,  wrote:

  Hi Tim

  Thanks for the reply. 

  What should be dspace.ui.url and solr.server (in local.cfg) since I am using 
two frontends in two different servers?. Dspace backend is in common NAS 
mounted on /dspace. 
  I am only confused how do I make my backend pointing to frontend since there 
are 2 frontends. 

  Individually, each Dspace instance works fine. But how do I load balance 
them? at least I need to load balance front end UI.

  Please note my postgres servers are in already HA in two different servers. 

  With Warm Regards
  Ravi 



  From: DSpace Technical Support 
  Sent: Monday, July 31, 2023 8:31 PM
  To: DSpace Technical Support 
  Subject: Re: [dspace-tech] Issue with Two Dspace servers with common NAS for 
bitstore (assetstore)

  Hi Ravi,

  I've not done this myself before, but you might want to look closely at the 
underlying error behind that 500 exception.  Sometimes a simple configuration 
issue can be the cause of the 500. 

  Here's how to find the underlying error: 
https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

  Here's common causes for 500 exceptions: 
https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-%22500ServiceUnavailable%22fromtheUserInterface

  One other thing to check is that the backend (REST API) "trusts" the User 
Interface.  This is controlled by the "rest.cors.allowed-origins" setting (in 
the rest.cfg). That setting must list all web-based clients which are using the 
REST API, otherwise they may be blocked with a 500 exception.

  Tim


  On Sunday, July 30, 2023 at 12:32:43 PM UTC-5 ravi...@gmail.com wrote:

Hi Mark, 
Thanks for the suggestion but still the same problem. 

I have tried below 
1. Single solr service but still same problem, but I need solr also in HA 
mode
2. Kept Dspace backend in common NAS but can specify only one frontend URL 
and one backend URL in local.cfg. Only one DSpace instance works at a time, the 
other one shows error 500. But again items/collections/communities created in 
one cannot be seen in another even though, DSpace backend is common to both the 
frontends. 

Does anyone have any idea or suggestion on at least DSpace frontend HA with 
a common DSpace backend?

Regards
Ravi Konila


On Tuesday, July 25, 2023 at 10:26:18 PM UTC+5:30 Mark H. Wood wrote:

  On Tue, Jul 25, 2023 at 10:14:10PM +0530, Ravi Konila wrote: 
  > I have successfully installed two Dspace 7.6 servers with a common NAS 
storage connected to both the servers used for bitstore/assetstore. 
  > Both the servers works fine individually with the shared storage. But 
items/community/collection created in one is not visible in other one. 
  > Please note that, both the servers use same Postgresql 15 server/db. 
  > 
  > The Dspace configurations are identical (dspace and dspace-ui). Both 
can communicate successfully to common Dspace database. 
  > 
  > Could anyone please clarify, if someone has done & configured load 
balancing or HA between two Dspace servers using shared storage (NAS). 
  > Please guide me to take this forward. 

  I have not attempted this. But I think that the two instances must 
  also share a single Solr instance. 

  -- 
  Mark H. Wood 
  Lead Technology Analyst 

  University Library 
  Indiana University - Purdue University Indianapolis 
  755 W. Michigan Street 
  Indianapolis, IN 46202 
  317-274-0749 
  www.ulib.iupui.edu 

  -- 
  All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
  --- 
  You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
  To unsubscribe from this group and stop receiving emails from it, send an 
email to dspace-tech+unsubscr...@googlegroups.com.
  To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/80dc838f-935b-4b85-8c80-8feecf7e41f4n%40googlegroups.com.

  -- 
  All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
  --- 
  You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" 

[dspace-tech] An issue with AIP import?

[Chris Clawson]

Please check my attempt! I have exported several items from my production 
server. I attempted to import them to my test system as new items to a test 
collection. These items exist elsewhere in my test system, but isn't that 
okay when using -s submit mode?
My test collection handle is MHS-01376/6883. The entire command line import 
was:
/opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
MHS-01376/6883 /home/chrisc/export2/6563.zip . I expected a new item to be 
added to MHS-01376/6883

The terminal responded with:
/opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
MHS-01376/6883 /home/chrisc/export2/6563.zip
Destination parents:
Owner: MHS-01376/6883
Ingesting package located at /home/chrisc/export2/6563.zip
CREATED new DSpace ITEM [ hdl=MHS-01376/6563, 
dbID=4ec3be54-d47d-4a46-bb9e-5c665c7aaba7 ]

## NO! it used the original item handle, rather than assigning a new 
one. The importer copied the archive contents to the existing 
MHS-01376/6563 (in the other collection), duplicating all the metadata and 
bitstreams, besides clobbering the 33 image iiif gallery.
Please comment and show me what I am doing wrong.
C. (using DSpace 7.6)

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/c58ec1d6-866c-4d30-9bf0-b1aecdb795c9n%40googlegroups.com.

[dspace-tech] An issue with AIP import?

[Chris Clawson]

Please check my attempt! I have exported sever items from my production 
server. I attempted to import them to my test system as new items to a test 
collection. These items exist elsewhere in my test system, but isn't that 
okay when using -s submit mode?
My test collection handle is MHS-01376/6883. The entire command line import 
was:
/opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
MHS-01376/6883 /home/chrisc/export2/6563.zip . I expected a new item to be 
added to MHS-01376/6883

The terminal responded with:
/opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
MHS-01376/6883 /home/chrisc/export2/6563.zip
Destination parents:
Owner: MHS-01376/6883
Ingesting package located at /home/chrisc/export2/6563.zip
CREATED new DSpace ITEM [ hdl=MHS-01376/6563, 
dbID=4ec3be54-d47d-4a46-bb9e-5c665c7aaba7 ]

## NO! it used the original item handle, rather than assigning a new 
one. The importer copied the archive contents to the existing 
MHS-01376/6563, duplicating all the metadata and bitstreams, besides 
clobbering the 33 image iiif gallery.
Please comment and show me what I am doing wrong.
C. DSpace 7.6

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/1aea43d5-f18f-4421-8787-fc54e7752e64n%40googlegroups.com.

[dspace-tech] Re: An issue with AIP import?

[Chris Clawson]

Sorry - This is using DSpace 7.6

On Monday, July 31, 2023 at 7:27:34 PM UTC-4 Chris Clawson wrote:

> Please check my attempt! I have exported sever items from my production 
> server. I attempted to import them to my test system as new items to a *test 
> collection*. These items exist elsewhere in my test system, but isn't 
> that okay when using -s submit mode?
> My test collection handle is MHS-01376/6883. The entire command line 
> import was:
> /opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
> MHS-01376/6883 /home/chrisc/export2/6563.zip . I expected a new item to be 
> added to MHS-01376/6883 
>
> The terminal responded with:
> /opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
> MHS-01376/6883 /home/chrisc/export2/6563.zip
> Destination parents:
> Owner: MHS-01376/6883
> Ingesting package located at /home/chrisc/export2/6563.zip
> CREATED new DSpace ITEM [ hdl=MHS-01376/6563, 
> dbID=4ec3be54-d47d-4a46-bb9e-5c665c7aaba7 ]
>
> ## NO! it used the original item handle, rather than assigning a new 
> one. The importer copied the archive contents to the existing 
> MHS-01376/6563, duplicating all the metadata and bitstreams, besides 
> clobbering the 33 image iiif gallery.
> Please comment and show me what I am doing wrong.
> C.
>

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/25eb6aa8-9e78-4c5a-91b2-d1f174088ef4n%40googlegroups.com.

[dspace-tech] An issue with AIP import?

[Chris Clawson]

Please check my attempt! I have exported sever items from my production 
server. I attempted to import them to my test system as new items to a *test 
collection*. These items exist elsewhere in my test system, but isn't that 
okay when using -s submit mode?
My test collection handle is MHS-01376/6883. The entire command line import 
was:
/opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
MHS-01376/6883 /home/chrisc/export2/6563.zip . I expected a new item to be 
added to MHS-01376/6883 

The terminal responded with:
/opt/dspace/bin/dspace packager -s -t AIP -e ch...@x.org -p 
MHS-01376/6883 /home/chrisc/export2/6563.zip
Destination parents:
Owner: MHS-01376/6883
Ingesting package located at /home/chrisc/export2/6563.zip
CREATED new DSpace ITEM [ hdl=MHS-01376/6563, 
dbID=4ec3be54-d47d-4a46-bb9e-5c665c7aaba7 ]

## NO! it used the original item handle, rather than assigning a new 
one. The importer copied the archive contents to the existing 
MHS-01376/6563, duplicating all the metadata and bitstreams, besides 
clobbering the 33 image iiif gallery.
Please comment and show me what I am doing wrong.
C.

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/308c995f-eedd-48e5-96ce-cf2d600853edn%40googlegroups.com.

Re: [dspace-tech] workflow "approve" issues

[James Holobetz]

I appreciate your detailed feedback.

What you have detailed is exactly what methodology/process we are using as
well. I can enter it properly, can view it, claim it, and edit
it, return it to the pool, (I haven't tried to reject). My only issue is
that I can not "Approve" it properly after initial entry. The anomaly is
that I can "Approve" it after doing an "Edit." That is the only underlying
issue. Nothing else. Everything else works properly.

James

On Mon, Jul 31, 2023 at 4:41 PM Fitchett, Deborah <
deborah.fitch...@lincoln.ac.nz> wrote:

> You mention you’re using a multi-step process, so let me describe how our
> two-step process has been working for me in testing 7.4, in case that
> shines any light on your case:
>
>
>
>- The item is submitted.
>- It shows in the workflow task list as “Waiting for controller”
>- I claim it – it now shows as “Validation”
>- I can either edit, reject, or approve (ie workflow step 2 aka
>“editstep”)
>- If I approve it (without editing), it appears to disappear from the
>workflow. I need to refresh the screen to see it again in the workflow
>list, now showing as “Waiting for controller” again
>- I claim it again – it shows as “Validation” again – and I can either
>edit or approve (ie workflow step 3 aka “finaleditstep”)
>- If I approve it (without editing), it disappears from the workflow
>and is now published in the collection as expected.
>
>
>
> The status labels “Waiting for controller” and “Validation” are confusing
> in this kind of multi-step process because they actually have nothing to do
> with the steps, and there’s no way currently to add a label to show what
> step it’s at.  (See https://github.com/DSpace/dspace-angular/issues/1609
> for a description of a possible solution to this if someone’s interested in
> volunteering….)
>
>
>
> So possibly that’s part of what’s causing confusion for you?
>
>
>
> And/or you may be seeing a difference in behaviour between directly
> approving vs editing-then-approving because when you edit-then-approve, the
> process of returning from the item view to the workflow list reloads and
> updates that list. But if you approve direct from the workflow list, the
> list doesn’t fully update so the item seems to disappear from it and you
> need to refresh the page to see it.
>
>
>
> Deborah
>
>
>
> *From:* dspace-tech@googlegroups.com  *On
> Behalf Of *James Holobetz
> *Sent:* Tuesday, August 1, 2023 6:40 AM
> *To:* dspace-tech@googlegroups.com
> *Subject:* [dspace-tech] workflow "approve" issues
>
>
>
> You don't often get email from jholob...@gmail.com. Learn why this is
> important 
>
>
>
> *Caution:* This email originated from outside our organisation. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Hi Everybody,
>
>
>
> I am experiencing weird behaviour when entering an item that has a
> multi-step process. Entering the item is fine and so is review and edit.
> When I try to "Approve" it for public consumption, the progress bar is
> green and it appears to remove it from the "Workflow tasks" area. But the
> item is not released and when you go back to the Workflow tasks area, the
> item is still there.The only time it successfully releases it is when,
> during the process, you edit something (even something as simple as remove
> and add back a period in the abstract). Nothing shows up in the logs at
> all. I have validated both the item-submission.xml and the
> submission-forms.xml. I am at a loss.
>
>
>
> For reference, we are using DSpace 7.6 and also, we ported our old
> input-forms.xml and item-submission.xml files and used the "./dspace
> submission-forms-migrate" script.
>
>
>
> Best regards,
>
>
>
> James Holobetz
>
> --
> All messages to this mailing list should adhere to the Code of Conduct:
> https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dspace-tech/CAAosP7WgOLej_%3DqYSZCUKrEQUz%2B_k-Eu%2Bb4%3DtFQVvqywMb3FDA%40mail.gmail.com
> 
> .
>
> --
>
> "The contents of this e-mail (including any attachments) may be
> confidential and/or subject to copyright. Any unauthorised use,
> distribution, or copying of the contents is expressly prohibited. If you
> have received this e-mail in error, please advise the sender by return
> e-mail or telephone and then delete this e-mail together with all
> attachments from your system."
>

-- 
All messages to this 

RE: [dspace-tech] workflow "approve" issues

[Fitchett, Deborah]

You mention you’re using a multi-step process, so let me describe how our 
two-step process has been working for me in testing 7.4, in case that shines 
any light on your case:


  *   The item is submitted.
  *   It shows in the workflow task list as “Waiting for controller”
  *   I claim it – it now shows as “Validation”
  *   I can either edit, reject, or approve (ie workflow step 2 aka “editstep”)
  *   If I approve it (without editing), it appears to disappear from the 
workflow. I need to refresh the screen to see it again in the workflow list, 
now showing as “Waiting for controller” again
  *   I claim it again – it shows as “Validation” again – and I can either edit 
or approve (ie workflow step 3 aka “finaleditstep”)
  *   If I approve it (without editing), it disappears from the workflow and is 
now published in the collection as expected.

The status labels “Waiting for controller” and “Validation” are confusing in 
this kind of multi-step process because they actually have nothing to do with 
the steps, and there’s no way currently to add a label to show what step it’s 
at.  (See https://github.com/DSpace/dspace-angular/issues/1609 for a 
description of a possible solution to this if someone’s interested in 
volunteering….)

So possibly that’s part of what’s causing confusion for you?

And/or you may be seeing a difference in behaviour between directly approving 
vs editing-then-approving because when you edit-then-approve, the process of 
returning from the item view to the workflow list reloads and updates that 
list. But if you approve direct from the workflow list, the list doesn’t fully 
update so the item seems to disappear from it and you need to refresh the page 
to see it.

Deborah

From: dspace-tech@googlegroups.com  On Behalf Of 
James Holobetz
Sent: Tuesday, August 1, 2023 6:40 AM
To: dspace-tech@googlegroups.com
Subject: [dspace-tech] workflow "approve" issues

You don't often get email from jholob...@gmail.com. 
Learn why this is important

Caution: This email originated from outside our organisation. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi Everybody,

I am experiencing weird behaviour when entering an item that has a multi-step 
process. Entering the item is fine and so is review and edit. When I try to 
"Approve" it for public consumption, the progress bar is green and it appears 
to remove it from the "Workflow tasks" area. But the item is not released and 
when you go back to the Workflow tasks area, the item is still there.The only 
time it successfully releases it is when, during the process, you edit 
something (even something as simple as remove and add back a period in the 
abstract). Nothing shows up in the logs at all. I have validated both the 
item-submission.xml and the submission-forms.xml. I am at a loss.

For reference, we are using DSpace 7.6 and also, we ported our old 
input-forms.xml and item-submission.xml files and used the "./dspace 
submission-forms-migrate" script.

Best regards,

James Holobetz
--
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/CAAosP7WgOLej_%3DqYSZCUKrEQUz%2B_k-Eu%2Bb4%3DtFQVvqywMb3FDA%40mail.gmail.com.



"The contents of this e-mail (including any attachments) may be confidential 
and/or subject to copyright. Any unauthorised use, distribution, or copying of 
the contents is expressly prohibited. If you have received this e-mail in 
error, please advise the sender by return e-mail or telephone and then delete 
this e-mail together with all attachments from your system."

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/ME3PR01MB752400E0A4F9D51E33A41906C505A%40ME3PR01MB7524.ausprd01.prod.outlook.com.

[dspace-tech] workflow "approve" issues

[James Holobetz]

Hi Everybody,

I am experiencing weird behaviour when entering an item that has a
multi-step process. Entering the item is fine and so is review and edit.
When I try to "Approve" it for public consumption, the progress bar is
green and it appears to remove it from the "Workflow tasks" area. But the
item is not released and when you go back to the Workflow tasks area, the
item is still there.The only time it successfully releases it is when,
during the process, you edit something (even something as simple as remove
and add back a period in the abstract). Nothing shows up in the logs at
all. I have validated both the item-submission.xml and the
submission-forms.xml. I am at a loss.

For reference, we are using DSpace 7.6 and also, we ported our old
input-forms.xml and item-submission.xml files and used the "./dspace
submission-forms-migrate" script.

Best regards,

James Holobetz

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/CAAosP7WgOLej_%3DqYSZCUKrEQUz%2B_k-Eu%2Bb4%3DtFQVvqywMb3FDA%40mail.gmail.com.

Re: [dspace-tech] Issue with Two Dspace servers with common NAS for bitstore (assetstore)

[Raghwendra Narayan]

Hi Ravi,

U can use main DB to both front end.  It will work .  I am using similar
configuration.

Regards.

On Mon, 31 Jul, 2023, 21:43 Ravi Konila,  wrote:

> Hi Tim
>
> Thanks for the reply.
>
> What should be dspace.ui.url and solr.server (in local.cfg) since I am
> using two frontends in two different servers?. Dspace backend is in common
> NAS mounted on /dspace.
> I am only confused how do I make my backend pointing to frontend since
> there are 2 frontends.
>
> Individually, each Dspace instance works fine. But how do I load balance
> them? at least I need to load balance front end UI.
>
> Please note my postgres servers are in already HA in two different
> servers.
>
> With Warm Regards
> Ravi
>
>
> *From:* DSpace Technical Support
> *Sent:* Monday, July 31, 2023 8:31 PM
> *To:* DSpace Technical Support
> *Subject:* Re: [dspace-tech] Issue with Two Dspace servers with common
> NAS for bitstore (assetstore)
>
> Hi Ravi,
>
> I've not done this myself before, but you might want to look closely at
> the underlying error behind that 500 exception.  Sometimes a simple
> configuration issue can be the cause of the 500.
>
> Here's how to find the underlying error:
> https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)
>
> Here's common causes for 500 exceptions:
> https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-%22500ServiceUnavailable%22fromtheUserInterface
>
> One other thing to check is that the backend (REST API) "trusts" the User
> Interface.  This is controlled by the "rest.cors.allowed-origins" setting
> (in the rest.cfg). That setting must list all web-based clients which are
> using the REST API, otherwise they may be blocked with a 500 exception.
>
> Tim
>
> On Sunday, July 30, 2023 at 12:32:43 PM UTC-5 ravi...@gmail.com wrote:
>
>> Hi Mark,
>> Thanks for the suggestion but still the same problem.
>>
>> I have tried below
>> 1. Single solr service but still same problem, but I need solr also in HA
>> mode
>> 2. Kept Dspace backend in common NAS but can specify only one frontend
>> URL and one backend URL in local.cfg. Only one DSpace instance works at a
>> time, the other one shows error 500. But again
>> items/collections/communities created in one cannot be seen in another even
>> though, DSpace backend is common to both the frontends.
>>
>> Does anyone have any idea or suggestion on at least DSpace frontend HA
>> with a common DSpace backend?
>>
>> Regards
>> Ravi Konila
>>
>> On Tuesday, July 25, 2023 at 10:26:18 PM UTC+5:30 Mark H. Wood wrote:
>>
>>> On Tue, Jul 25, 2023 at 10:14:10PM +0530, Ravi Konila wrote:
>>> > I have successfully installed two Dspace 7.6 servers with a common NAS
>>> storage connected to both the servers used for bitstore/assetstore.
>>> > Both the servers works fine individually with the shared storage. But
>>> items/community/collection created in one is not visible in other one.
>>> > Please note that, both the servers use same Postgresql 15 server/db.
>>> >
>>> > The Dspace configurations are identical (dspace and dspace-ui). Both
>>> can communicate successfully to common Dspace database.
>>> >
>>> > Could anyone please clarify, if someone has done & configured load
>>> balancing or HA between two Dspace servers using shared storage (NAS).
>>> > Please guide me to take this forward.
>>>
>>> I have not attempted this. But I think that the two instances must
>>> also share a single Solr instance.
>>>
>>> --
>>> Mark H. Wood
>>> Lead Technology Analyst
>>>
>>> University Library
>>> Indiana University - Purdue University Indianapolis
>>> 755 W. Michigan Street
>>> Indianapolis, IN 46202
>>> 317-274-0749 <(317)%20274-0749>
>>> www.ulib.iupui.edu
>>>
>> --
> All messages to this mailing list should adhere to the Code of Conduct:
> https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dspace-tech/80dc838f-935b-4b85-8c80-8feecf7e41f4n%40googlegroups.com
> 
> .
>
> --
> All messages to this mailing list should adhere to the Code of Conduct:
> https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
> ---
> You received this message because you are subscribed to the Google Groups
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to dspace-tech+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dspace-tech/5ED817301F524186AB0B57F4DD19D1C3%40RAVIKONILAPC
> 

Re: [dspace-tech] Issue with Two Dspace servers with common NAS for bitstore (assetstore)

[Ravi Konila]

Hi Tim

Thanks for the reply. 

What should be dspace.ui.url and solr.server (in local.cfg) since I am using 
two frontends in two different servers?. Dspace backend is in common NAS 
mounted on /dspace. 
I am only confused how do I make my backend pointing to frontend since there 
are 2 frontends. 

Individually, each Dspace instance works fine. But how do I load balance them? 
at least I need to load balance front end UI.

Please note my postgres servers are in already HA in two different servers. 

With Warm Regards
Ravi 



From: DSpace Technical Support 
Sent: Monday, July 31, 2023 8:31 PM
To: DSpace Technical Support 
Subject: Re: [dspace-tech] Issue with Two Dspace servers with common NAS for 
bitstore (assetstore)

Hi Ravi,

I've not done this myself before, but you might want to look closely at the 
underlying error behind that 500 exception.  Sometimes a simple configuration 
issue can be the cause of the 500. 

Here's how to find the underlying error: 
https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

Here's common causes for 500 exceptions: 
https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-%22500ServiceUnavailable%22fromtheUserInterface

One other thing to check is that the backend (REST API) "trusts" the User 
Interface.  This is controlled by the "rest.cors.allowed-origins" setting (in 
the rest.cfg). That setting must list all web-based clients which are using the 
REST API, otherwise they may be blocked with a 500 exception.

Tim


On Sunday, July 30, 2023 at 12:32:43 PM UTC-5 ravi...@gmail.com wrote:

  Hi Mark, 
  Thanks for the suggestion but still the same problem. 

  I have tried below 
  1. Single solr service but still same problem, but I need solr also in HA mode
  2. Kept Dspace backend in common NAS but can specify only one frontend URL 
and one backend URL in local.cfg. Only one DSpace instance works at a time, the 
other one shows error 500. But again items/collections/communities created in 
one cannot be seen in another even though, DSpace backend is common to both the 
frontends. 

  Does anyone have any idea or suggestion on at least DSpace frontend HA with a 
common DSpace backend?

  Regards
  Ravi Konila


  On Tuesday, July 25, 2023 at 10:26:18 PM UTC+5:30 Mark H. Wood wrote:

On Tue, Jul 25, 2023 at 10:14:10PM +0530, Ravi Konila wrote: 
> I have successfully installed two Dspace 7.6 servers with a common NAS 
storage connected to both the servers used for bitstore/assetstore. 
> Both the servers works fine individually with the shared storage. But 
items/community/collection created in one is not visible in other one. 
> Please note that, both the servers use same Postgresql 15 server/db. 
> 
> The Dspace configurations are identical (dspace and dspace-ui). Both can 
communicate successfully to common Dspace database. 
> 
> Could anyone please clarify, if someone has done & configured load 
balancing or HA between two Dspace servers using shared storage (NAS). 
> Please guide me to take this forward. 

I have not attempted this. But I think that the two instances must 
also share a single Solr instance. 

-- 
Mark H. Wood 
Lead Technology Analyst 

University Library 
Indiana University - Purdue University Indianapolis 
755 W. Michigan Street 
Indianapolis, IN 46202 
317-274-0749 
www.ulib.iupui.edu 

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/80dc838f-935b-4b85-8c80-8feecf7e41f4n%40googlegroups.com.

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/5ED817301F524186AB0B57F4DD19D1C3%40RAVIKONILAPC.

[dspace-tech] DSpace 7.6 Item Access Conditions Step in submission

[amtuan...@gmail.com]

Hello

I have enabled the Item Access Conditions step in the item-submission.xml 
as per the documentation 
here 
https://wiki.lyrasis.org/display/DSDOC7x/Submission+User+Interface#SubmissionUserInterface-ConfiguringtheItemAccessConditionsstep

I have restarted tomcat and angular ui. However there is no change in the 
submission form.

Is something else missing? See attached item-submission.xml


Thanks,
Tuan

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/89a287d0-262a-4eb6-8b7c-bc46e1d05195n%40googlegroups.com.























































org.dspace.app.rest.submit.step.CollectionStep
collection
submission




submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.steptwo
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form



submit.progressbar.upload
org.dspace.app.rest.submit.step.UploadStep
upload


submit.progressbar.license
org.dspace.app.rest.submit.step.LicenseStep
license
submission




submit.progressbar.CClicense
org.dspace.app.rest.submit.step.CCLicenseStep
	cclicense


		

submit.progressbar.accessCondition
org.dspace.app.rest.submit.step.AccessConditionStep
accessCondition





submit.progressbar.ExtractMetadataStep
org.dspace.app.rest.submit.step.ExtractMetadataStep
extract




submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form


submit.progressbar.describe.stepone
org.dspace.app.rest.submit.step.DescribeStep
submission-form




Sample
org.dspace.submit.step.SampleStep
sample



submit.progressbar.sherpapolicy
org.dspace.app.rest.submit.step.SherpaPolicyStep
sherpaPolicy




submit.progressbar.identifiers
org.dspace.app.rest.submit.step.ShowIdentifiersStep
identifiers








































		








  

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[DSpace Technical Support]

Hi Sascha,

Yes, the demo site has it's own "ui-demo" branch for the UI at this time: 
https://github.com/DSpace/dspace-angular/compare/ui-demo

That said, I'll admit we are currently migrating the demo site to a new 
platform, and that new platform won't use the same GitHub branch-based 
setup anymore.  So, this branch unfortunately won't be a resource for much 
longer.  The branch already is incomplete though, as it cannot contain any 
private information (like the private application keys used to connect the 
demo to the ORCID sandbox or similar).

That said, we might be able to find a different way to simply document the 
enabled features on the wiki or similar.

Tim
On Monday, July 31, 2023 at 10:40:04 AM UTC-5 Sascha Szott wrote:

> Hi Tim,
>
> SSR is the missing keyword - thank you! I was not aware of the fact that 
> it is enabled.
>
> Is there a place (e.g. branch in Github) where we can see which frontend 
> configuration is taken into account to serve the public DSpace demo 
> instance? It would be helpful in the future to explain such differences.
>
> Best
> Sascha
>
>
> Am 31.07.23 um 17:28 schrieb DSpace Technical Support:
> > Hi Karol & Sascha,
> > 
> > I previously misunderstood when you were seeing these 401 responses. 
> >  Seeing them appear occasionally from the User Interface is *expected 
> > behavior*.  What is going on is that the frontend is checking 
> > permissions of the current user to see if they are allowed to 
> > export/import in order to provide the proper links in the User Interface 
> > if they have access.  If the user is allowed, this request returns a 
> > 200.  If they are not allowed, it returns a 401.  It is therefore *not* 
> > an error, but a permissions check... as a 401 response simply means you 
> > don't have permissions.
> > 
> > Simply put, these are safe to ignore.  You *will* sometimes see the User 
> > Interface "ask" the REST API if a user has permissions , or if a feature 
> > is enabled.  The REST API then will sometimes respond with 401 or 404 or 
> > similar... this is expected behavior at this time.  (It might be 
> > possible to reanalyze if there's a different way to achieve this... but 
> > this is how it works currently. You are welcome to log a bug ticket 
> > though in our ticketing system if you want: 
> > https://github.com/DSpace/dspace-angular/issues)
> > 
> > That said, if this is filling up your logs you could use caching to 
> > ensure the check happens less frequently.
> > 
> > On the demo site, we have anonymous page caching turned on.  This is why 
> > it's not visible there as frequently (it still may appear occasionally), 
> > as the pages are cached and this permission check happens /less 
> > frequently/.  See this guide for how to enable that 
> > caching: 
> https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)
> > 
> > Hopefully that helps explain what is going on better.  At a second 
> > glance, I think these are just permissions checks for current users. 
> > But, turning on caching should decrease their frequency.
> > 
> > Tim
> > On Saturday, July 29, 2023 at 7:05:20 AM UTC-5 karols...@gmail.com 
> wrote:
> > 
> > Hi Tim, Sascha,
> > 
> > Tim, it looks like my first entry, is not correlated with the 401
> > error - it's just a coincidence. I don't have any additional
> > scripts, nor do I see any bots in the logs that are trying to access
> > this content: /server/api/system/scripts/metadata-import
> > 
> > Sascha, it directed me to conduct tests:
> > 
> > 1) I blocked the firewall for everyone opened only for my computer
> > and started opening the main page of my repository. And to my
> > surprise, errors started to appear:
> > *GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
> > "-" "Mozilla/5.0 (Linux x64) node.js/12.22.12
> > v8/7.8.279.23-node.57"* and
> > *GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
> > *"-" "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"*
> > even though I only opened the main repository page in the browser.
> > Opening a collection, community, item view or anything else does not
> > cause these errors.
> > 
> > 2) I disabled the frontend (angular) left the backend enabled and
> > the errors stopped appearing, which excludes bots that try to get
> > into the
> > /server/api/system/scripts/metadata-import
> > /server/api/system/scripts/metadata-export
> > 
> > Tim, in summary, I have exactly the same problem as Sascha,
> > everytime when I opening, refreshing the main page it generating 2
> > errors :
> > **
> > *GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
> > *
> > *GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
> > **
> > 
> > Comes to my mind, because after migrating from dspace6 to dspace7 I
> > once carried out the export and import process of collections from
> > the Administrator - first in simulation mode then 

Re: [dspace-tech] Re: Seemingly crazy catch 22 Dspace DB migration loop question!!!

['Tim Donohue' via DSpace Technical Support]

Hi Euler,

This 5.7 migration is obsolete & it has caused issues with others as well.  See 
this old dspace-tech mailing list thread: 
https://groups.google.com/g/dspace-tech/c/PlOA1WMvd4M/m/eBVE5RfhBgAJ

The solution is to use the new "./dspace database skip" command provided as of 
DSpace 7.5 and skip this problematic migration by running:


./dspace database skip "5.7.2017.04.11"


This is safe to do because the migration is obsolete​.

Tim

From: dspace-tech@googlegroups.com  on behalf of 
euler 
Sent: Monday, July 31, 2023 6:05 AM
To: DSpace Technical Support 
Subject: Re: [dspace-tech] Re: Seemingly crazy catch 22 Dspace DB migration 
loop question!!!

Hi Tim,

Apologies for not reporting back sooner. As per your suggestion, I removed the 
SQL you mentioned, performed 'mvn clean package', and 'ant update'. I did not 
receive any errors when running 'dspace database repair', but when I run 
'dspace database migrate ignored', the console returned a lot of errors too 
long to post here. Please see the attached text file from the output of my 
console. I will try to restore this repository in a local instance with the 
latest 6x version and try to run 'dspace database migrate ignored' from there. 
I suspect there is something wrong with this particular instance because when I 
run the command 'dspace database migrate ignored' on this repository which is 
running version 6.3, it returned this error:

Database URL: jdbc:postgresql://localhost:5432/dspace
Migrating database to latest version AND running previously "Ignored" 
migrations... (Check logs for details)
Migration exception:
java.sql.SQLException: Flyway migration error occurred
at org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:673)
at org.dspace.storage.rdbms.DatabaseUtils.main(DatabaseUtils.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
Caused by: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException:
Migration 
V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql failed
-
SQL State  : 42703
Error Code : 0
Message: ERROR: column "resource_type_id" does not exist
Location   : 
org/dspace/storage/rdbms/sqlmigration/postgres/V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql
 
(c:\DSpace\file:\C:\DSpace\lib\dspace-api-6.3.jar!\org\dspace\storage\rdbms\sqlmigration\postgres\V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql)
Line   : 16
Statement  : CREATE INDEX metadatavalue_resource_type_id_idx ON metadatavalue 
(resource_type_id)

at org.flywaydb.core.internal.dbsupport.SqlScript.execute(SqlScript.java:117)
at 
org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:71)
at org.flywaydb.core.internal.command.DbMigrate.doMigrate(DbMigrate.java:352)
at org.flywaydb.core.internal.command.DbMigrate.access$1100(DbMigrate.java:47)
at 
org.flywaydb.core.internal.command.DbMigrate$4.doInTransaction(DbMigrate.java:308)
at 
org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72)
at 
org.flywaydb.core.internal.command.DbMigrate.applyMigration(DbMigrate.java:305)
at org.flywaydb.core.internal.command.DbMigrate.access$1000(DbMigrate.java:47)
at 
org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:230)
at 
org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:173)
at 
org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72)
at org.flywaydb.core.internal.command.DbMigrate.migrate(DbMigrate.java:173)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:959)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:917)
at org.flywaydb.core.Flyway.execute(Flyway.java:1373)
at org.flywaydb.core.Flyway.migrate(Flyway.java:917)
at org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:662)
... 7 more
Caused by: org.postgresql.util.PSQLException: ERROR: column "resource_type_id" 
does not exist
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2422)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2167)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:307)
at 

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[Sascha Szott]

Hi Tim,

SSR is the missing keyword - thank you! I was not aware of the fact that 
it is enabled.


Is there a place (e.g. branch in Github) where we can see which frontend 
configuration is taken into account to serve the public DSpace demo 
instance? It would be helpful in the future to explain such differences.


Best
Sascha


Am 31.07.23 um 17:28 schrieb DSpace Technical Support:

Hi Karol & Sascha,

I previously misunderstood when you were seeing these 401 responses.  
  Seeing them appear occasionally from the User Interface is *expected 
behavior*.  What is going on is that the frontend is checking 
permissions of the current user to see if they are allowed to 
export/import in order to provide the proper links in the User Interface 
if they have access.  If the user is allowed, this request returns a 
200.  If they are not allowed, it returns a 401.  It is therefore *not* 
an error, but a permissions check... as a 401 response simply means you 
don't have permissions.


Simply put, these are safe to ignore.  You *will* sometimes see the User 
Interface "ask" the REST API if a user has permissions , or if a feature 
is enabled.  The REST API then will sometimes respond with 401 or 404 or 
similar... this is expected behavior at this time.  (It might be 
possible to reanalyze if there's a different way to achieve this... but 
this is how it works currently. You are welcome to log a bug ticket 
though in our ticketing system if you want: 
https://github.com/DSpace/dspace-angular/issues)


That said, if this is filling up your logs you could use caching to 
ensure the check happens less frequently.


On the demo site, we have anonymous page caching turned on.  This is why 
it's not visible there as frequently (it still may appear occasionally), 
as the pages are cached and this permission check happens /less 
frequently/.  See this guide for how to enable that 
caching: https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)


Hopefully that helps explain what is going on better.  At a second 
glance, I think these are just permissions checks for current users.  
But, turning on caching should decrease their frequency.


Tim
On Saturday, July 29, 2023 at 7:05:20 AM UTC-5 karols...@gmail.com wrote:

Hi Tim, Sascha,

Tim, it looks like my first entry, is not correlated with the 401
error - it's just a coincidence. I don't have any additional
scripts, nor do I see any bots in the logs that are trying to access
this content: /server/api/system/scripts/metadata-import

Sascha, it directed me to conduct tests:

1) I blocked the firewall for everyone opened only for my computer
and started opening the main page of my repository. And to my
surprise, errors started to appear:
*GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
"-" "Mozilla/5.0 (Linux x64) node.js/12.22.12
v8/7.8.279.23-node.57"* and
*GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
*"-" "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"*
even though I only opened the main repository page in the browser.
Opening a collection, community, item view or anything else does not
cause these errors.

2) I disabled the frontend (angular) left the backend enabled and
the errors stopped appearing, which excludes bots that try to get
into the
/server/api/system/scripts/metadata-import
/server/api/system/scripts/metadata-export

Tim, in summary, I have exactly the same problem as Sascha,
everytime when I opening, refreshing the main page it generating 2
errors :
**
*GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514
*
*GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
**

Comes to my mind, because after migrating from dspace6 to dspace7 I
once carried out the export and import process of collections from
the Administrator - first in simulation mode then in normal mode
everything performed correctly, did you Sascha take such actions?
Maybe something "crashed" in Angular after this action?

Thanks guys,

Karol

piątek, 28 lipca 2023 o 18:44:44 UTC+2 Sascha Szott napisał(a):

Hi Karol,

did you checked the requests to /metadata-import and
/metadata-export
are issued when you access the start page of your DSpace instance?

Currently, we see two 401 requests everytime we open the home
page of
our DSpace instance. We are running DSpace 7.5 / CRIS 2023.01.
We are
not able to reproduce this behaviour in the public DSpace demo
instances.

The backend response is

{
"timestamp": "2023-07-28T16:32:41.705+00:00",
"status": 401,
"error": "Unauthorized",
"message": "Authentication is required",
"path": 

[dspace-tech] Re: Dspace API | apply filters

[DSpace Technical Support]

Hi,

See the Search Endpoints documented in our REST 
Contract: https://github.com/DSpace/RestContract/blob/main/search-endpoint.md

It's also worth noting that you can easily discover which DSpace REST API 
endpoints are used by the User Interface using your browser.  Just open up 
the DevTools and look at the Network tab.  Then perform some action in the 
User Interface and you'll see every REST API call it makes.  This is 
possible because the User Interface runs entirely in your browser, so it 
has to make requests to the REST API to gather all data to display & those 
requests always appear on that "Network" tab.

Tim

On Thursday, July 27, 2023 at 12:20:24 AM UTC-5 raja...@gmail.com wrote:

> Hi Team,
>
> Kindly share the Dspace collection listing API and scope based Items 
> listing API in Dspace. 
>
> We need below fields only for response, can you please suggest how to 
> apply the filters in that API.
>
> dc.title
> Bitstream
> Item Name
>

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/6ffbe5e0-ef69-441b-8d6e-bbecfd378fb4n%40googlegroups.com.

Re: [dspace-tech] Re: DSpace 7.5 - status:401 exception: Access is denied

[DSpace Technical Support]

Hi Karol & Sascha,

I previously misunderstood when you were seeing these 401 responses.  
 Seeing them appear occasionally from the User Interface is *expected 
behavior*.  What is going on is that the frontend is checking permissions 
of the current user to see if they are allowed to export/import in order to 
provide the proper links in the User Interface if they have access.  If the 
user is allowed, this request returns a 200.  If they are not allowed, it 
returns a 401.  It is therefore *not* an error, but a permissions check... 
as a 401 response simply means you don't have permissions.

Simply put, these are safe to ignore.  You *will* sometimes see the User 
Interface "ask" the REST API if a user has permissions , or if a feature is 
enabled.  The REST API then will sometimes respond with 401 or 404 or 
similar... this is expected behavior at this time.  (It might be possible 
to reanalyze if there's a different way to achieve this... but this is how 
it works currently. You are welcome to log a bug ticket though in our 
ticketing system if you want: 
https://github.com/DSpace/dspace-angular/issues)

That said, if this is filling up your logs you could use caching to ensure 
the check happens less frequently.

On the demo site, we have anonymous page caching turned on.  This is why 
it's not visible there as frequently (it still may appear occasionally), as 
the pages are cached and this permission check happens *less frequently*.  
See this guide for how to enable that 
caching: 
https://wiki.lyrasis.org/display/DSDOC7x/User+Interface+Configuration#UserInterfaceConfiguration-CacheSettings-ServerSideRendering(SSR)

Hopefully that helps explain what is going on better.  At a second glance, 
I think these are just permissions checks for current users.  But, turning 
on caching should decrease their frequency.

Tim
On Saturday, July 29, 2023 at 7:05:20 AM UTC-5 karols...@gmail.com wrote:

> Hi Tim, Sascha,
>
> Tim, it looks like my first entry, is not correlated with the 401 error 
> - it's just a coincidence. I don't have any additional scripts, nor do I 
> see any bots in the logs that are trying to access this content: 
> /server/api/system/scripts/metadata-import
>
> Sascha, it directed me to conduct tests:
>
> 1) I blocked the firewall for everyone opened only for my computer and 
> started opening the main page of my repository. And to my surprise, errors 
> started to appear:
> *GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 "-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"* and 
> *GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514* *"-" 
> "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"*
> even though I only opened the main repository page in the browser. Opening 
> a collection, community, item view or anything else does not cause these 
> errors.
>
> 2) I disabled the frontend (angular) left the backend enabled and the 
> errors stopped appearing, which excludes bots that try to get into the  
> /server/api/system/scripts/metadata-import
> /server/api/system/scripts/metadata-export
>
> Tim, in summary, I have exactly the same problem as Sascha, everytime when 
> I opening, refreshing the main page it generating 2 errors :
>
> *GET /server/api/system/scripts/metadata-import HTTP/1.1" 401 1514 *
> *GET /server/api/system/scripts/metadata-export HTTP/1.1" 401 1514*
>
> Comes to my mind, because after migrating from dspace6 to dspace7 I once 
> carried out the export and import process of collections from the 
> Administrator - first in simulation mode then in normal mode everything 
> performed correctly, did you Sascha take such actions? Maybe something 
> "crashed" in Angular after this action? 
>
> Thanks guys,
>
> Karol
>
> piątek, 28 lipca 2023 o 18:44:44 UTC+2 Sascha Szott napisał(a):
>
>> Hi Karol, 
>>
>> did you checked the requests to /metadata-import and /metadata-export 
>> are issued when you access the start page of your DSpace instance? 
>>
>> Currently, we see two 401 requests everytime we open the home page of 
>> our DSpace instance. We are running DSpace 7.5 / CRIS 2023.01. We are 
>> not able to reproduce this behaviour in the public DSpace demo instances. 
>>
>> The backend response is 
>>
>> { 
>> "timestamp": "2023-07-28T16:32:41.705+00:00", 
>> "status": 401, 
>> "error": "Unauthorized", 
>> "message": "Authentication is required", 
>> "path": "/server/api/system/scripts/metadata-import" 
>> } 
>>
>> { 
>> "timestamp": "2023-07-28T16:32:41.691+00:00", 
>> "status": 401, 
>> "error": "Unauthorized", 
>> "message": "Authentication is required", 
>> "path": "/server/api/system/scripts/metadata-export" 
>> } 
>>
>> We have no idea how to configure the system properly and disable the 
>> requests. 
>>
>> Best 
>> Sascha 
>>
>>
>> Am 28.07.23 um 16:56 schrieb DSpace Technical Support: 
>> > Hi Karol, 
>> > 
>> > A 401 HTTP code / exception means that the client is unauthorized (not 
>> > authenticated). 

Re: [dspace-tech] Re: Seemingly crazy catch 22 Dspace DB migration loop question!!!

[euler]

Hi Tim,

Apologies for not reporting back sooner. As per your suggestion, I removed 
the SQL you mentioned, performed 'mvn clean package', and 'ant update'. I 
did not receive any errors when running 'dspace database repair', but when 
I run 'dspace database migrate ignored', the console returned a lot of 
errors too long to post here. Please see the attached text file from the 
output of my console. I will try to restore this repository in a local 
instance with the latest 6x version and try to run 'dspace database migrate 
ignored' from there. I suspect there is something wrong with this 
particular instance because when I run the command 'dspace database migrate 
ignored' on this repository which is running version 6.3, it returned this 
error:

Database URL: jdbc:postgresql://localhost:5432/dspace
Migrating database to latest version AND running previously "Ignored" 
migrations... (Check logs for details)
Migration exception:
java.sql.SQLException: Flyway migration error occurred
at 
org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:673)
at org.dspace.storage.rdbms.DatabaseUtils.main(DatabaseUtils.java:187)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
Caused by: org.flywaydb.core.internal.dbsupport.FlywaySqlScriptException: 
Migration 
V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql 
failed
-
SQL State  : 42703
Error Code : 0
Message: ERROR: column "resource_type_id" does not exist
Location   : 
org/dspace/storage/rdbms/sqlmigration/postgres/V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql
 
(c:\DSpace\file:\C:\DSpace\lib\dspace-api-6.3.jar!\org\dspace\storage\rdbms\sqlmigration\postgres\V5.7_2017.04.11__DS-3563_Index_metadatavalue_resource_type_id_column.sql)
Line   : 16
Statement  : CREATE INDEX metadatavalue_resource_type_id_idx ON 
metadatavalue (resource_type_id)

at 
org.flywaydb.core.internal.dbsupport.SqlScript.execute(SqlScript.java:117)
at 
org.flywaydb.core.internal.resolver.sql.SqlMigrationExecutor.execute(SqlMigrationExecutor.java:71)
at 
org.flywaydb.core.internal.command.DbMigrate.doMigrate(DbMigrate.java:352)
at 
org.flywaydb.core.internal.command.DbMigrate.access$1100(DbMigrate.java:47)
at 
org.flywaydb.core.internal.command.DbMigrate$4.doInTransaction(DbMigrate.java:308)
at 
org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72)
at 
org.flywaydb.core.internal.command.DbMigrate.applyMigration(DbMigrate.java:305)
at 
org.flywaydb.core.internal.command.DbMigrate.access$1000(DbMigrate.java:47)
at 
org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:230)
at 
org.flywaydb.core.internal.command.DbMigrate$2.doInTransaction(DbMigrate.java:173)
at 
org.flywaydb.core.internal.util.jdbc.TransactionTemplate.execute(TransactionTemplate.java:72)
at org.flywaydb.core.internal.command.DbMigrate.migrate(DbMigrate.java:173)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:959)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:917)
at org.flywaydb.core.Flyway.execute(Flyway.java:1373)
at org.flywaydb.core.Flyway.migrate(Flyway.java:917)
at 
org.dspace.storage.rdbms.DatabaseUtils.updateDatabase(DatabaseUtils.java:662)
... 7 more
Caused by: org.postgresql.util.PSQLException: ERROR: column 
"resource_type_id" does not exist
at 
org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2422)
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2167)
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:307)
at org.postgresql.jdbc.PgStatement.executeCachedSql(PgStatement.java:293)
at org.postgresql.jdbc.PgStatement.executeWithFlags(PgStatement.java:270)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:266)
at 
org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:291)
at 
org.apache.commons.dbcp2.DelegatingStatement.execute(DelegatingStatement.java:291)
at 
org.flywaydb.core.internal.dbsupport.JdbcTemplate.executeStatement(JdbcTemplate.java:238)
at 
org.flywaydb.core.internal.dbsupport.SqlScript.execute(SqlScript.java:114)
... 23 more

Please note that the original version of DSpace that I used to install in 
this instance was version 6.0, so I wonder why it is complaining about 
scripts from version 5.7.

Hoping 

Re: [dspace-tech] Issue with Two Dspace servers with common NAS for bitstore (assetstore)

[DSpace Technical Support]

Hi Ravi,

I've not done this myself before, but you might want to look closely at the 
underlying error behind that 500 exception.  Sometimes a simple 
configuration issue can be the cause of the 500.

Here's how to find the underlying 
error: 
https://wiki.lyrasis.org/display/DSPACE/Troubleshoot+an+error#Troubleshootanerror-DSpace7.x(orabove)

Here's common causes for 500 
exceptions: 
https://wiki.lyrasis.org/display/DSDOC7x/Installing+DSpace#InstallingDSpace-%22500ServiceUnavailable%22fromtheUserInterface

One other thing to check is that the backend (REST API) "trusts" the User 
Interface.  This is controlled by the "rest.cors.allowed-origins" setting 
(in the rest.cfg). That setting must list all web-based clients which are 
using the REST API, otherwise they may be blocked with a 500 exception.

Tim

On Sunday, July 30, 2023 at 12:32:43 PM UTC-5 ravi...@gmail.com wrote:

> Hi Mark, 
> Thanks for the suggestion but still the same problem. 
>
> I have tried below
> 1. Single solr service but still same problem, but I need solr also in HA 
> mode
> 2. Kept Dspace backend in common NAS but can specify only one frontend URL 
> and one backend URL in local.cfg. Only one DSpace instance works at a time, 
> the other one shows error 500. But again items/collections/communities 
> created in one cannot be seen in another even though, DSpace backend is 
> common to both the frontends. 
>
> Does anyone have any idea or suggestion on at least DSpace frontend HA 
> with a common DSpace backend?
>
> Regards
> Ravi Konila
>
> On Tuesday, July 25, 2023 at 10:26:18 PM UTC+5:30 Mark H. Wood wrote:
>
>> On Tue, Jul 25, 2023 at 10:14:10PM +0530, Ravi Konila wrote: 
>> > I have successfully installed two Dspace 7.6 servers with a common NAS 
>> storage connected to both the servers used for bitstore/assetstore. 
>> > Both the servers works fine individually with the shared storage. But 
>> items/community/collection created in one is not visible in other one. 
>> > Please note that, both the servers use same Postgresql 15 server/db. 
>> > 
>> > The Dspace configurations are identical (dspace and dspace-ui). Both 
>> can communicate successfully to common Dspace database. 
>> > 
>> > Could anyone please clarify, if someone has done & configured load 
>> balancing or HA between two Dspace servers using shared storage (NAS). 
>> > Please guide me to take this forward. 
>>
>> I have not attempted this. But I think that the two instances must 
>> also share a single Solr instance. 
>>
>> -- 
>> Mark H. Wood 
>> Lead Technology Analyst 
>>
>> University Library 
>> Indiana University - Purdue University Indianapolis 
>> 755 W. Michigan Street 
>> Indianapolis, IN 46202 
>> 317-274-0749 <(317)%20274-0749> 
>> www.ulib.iupui.edu 
>>
>

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/80dc838f-935b-4b85-8c80-8feecf7e41f4n%40googlegroups.com.

[dspace-tech] Where can I change the URI in documents?

[Michel Montenegro]

*OK*
For example, on the website (Front) of Dspace, when I access the community,
the message appears

> "Permanent URI of this community http://localhost:4000/handle/123456789/1;


The message/path is correct! Points to localhost

When accessing a community specified the path is still correct.
Example: http://*localhost:4000*/handle/123456789/7

*ERROR*
But when I click on an Article/Post it shows me (File, Date, Authors,
Publisher, Collections, Keyword, citation and URI)

In case the URI is pointing to the wrong path, it should be localhost, how
can I solve this?
Example: http://*dspace.tjpa.jus.br/jspui *
/handle/123456789/1261

[image: image.png]


-- 
Atenciosamente,
*Michel Pinheiro Montenegro*
- *Bacharel* em Sistema de Informação
- [Lato Sensu] *Especialista* em Engenharia de Sistemas
- [Stricto Sensu] *Mestre* em Ciência da Computação
- [Stricto Sensu] *Doutorando* em Ciência da Computação

E-mail/Gtalk: michel.montene...@gmail.com

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/CADOAx_jYYvOHK3FCgUvSvhp%2B_wxyhJZ5t%3DAe30r7LVCEJ_%3D3Rg%40mail.gmail.com.