[dspace-tech] Re: AIP import - bug or my error?

2023-07-29 Thread Chris Clawson
I solved my problem (with Tim's suggestion) I didn't see any examples given 
for the -r restore option, which include specifying a parent directory. The 
following example does work. I just included the -p option to specify the 
new parent collection.  This now takes an old, single item AIP and 
'restores" it to a more recently created collection (MHS-01376/6864):
[dspace]/bin/dspace packager -r -a -k -t AIP -e ch...@mydomain.org -p 
MHS-01376/6864 i...@mhs-01376-5381.zip
Thanks for the direction

On Friday, July 28, 2023 at 5:09:37 PM UTC-4 Chris Clawson wrote:

> Thanks Tim,
> But I don't see any option with the  -R restore command to direct the 
> import to a new collection. The original collection no longer exists, so 
> how will the restore -r command work if the target collection no longer 
> exists?  My Wordpress site still refers to this old item and it's URI. I 
> prefer to direct it to a specific (and new) collection, but don't care too 
> much where it goes because I can always move it around later. I do need to 
> keep the item URI to respect the references elsewhere.
>
> On Wednesday, July 26, 2023 at 2:45:48 PM UTC-4 DSpace Technical Support 
> wrote:
>
>> Hi Chris,
>>
>> I think you might be missing the "-r" flag to tell the packager command 
>> that you want to use *restore* mode.  This will also default to setting 
>> "ignoreHandle=false", so that option shouldn't be needed.  See the 
>> instructions at 
>> https://wiki.lyrasis.org/display/DSDOC7x/AIP+Backup+and+Restore#AIPBackupandRestore-DefaultRestoreMode
>>
>> By default, if you don't specify "-r", then it defaults to "submit" mode 
>> which tries to assign a new URI.  For more on the differences between 
>> Submit & Restore, see this section of the docs:  
>> https://wiki.lyrasis.org/display/DSDOC7x/AIP+Backup+and+Restore#AIPBackupandRestore-IngestionModes
>>
>> That said, it does seem like the "ignoreHandle=false" option should have 
>> also worked with your command.  Not sure why it would not have worked, but 
>> you also may want to check the logs to see if there were errors reported.
>>
>> Tim
>>
>> On Tuesday, July 25, 2023 at 6:31:09 PM UTC-5 Chris Clawson wrote:
>>
>>> I just attempted to import an item that had been exported and deleted. I 
>>> wish to import it back to a new collection but want to preserve the 
>>> original and full handle. The importer imports the item only as new, 
>>> seemingly ignoring the -o option. 
>>> The example:
>>> /opt/dspace/bin/dspace packager -o ignoreHandle=false -t AIP -e 
>>> ch...@mydomain.org -p MHS-01376/6742 
>>> /home/chris/it...@mhs-01376-5381.zip
>>> A new item is created as MHS-01376-6855 and then added to my expected 
>>> collection. I want to keep the MHS-01376-5381 URI.
>>>
>>> I refer to this old URI in my wordpress site and don't want to run 
>>> around my blog posts and rename many occurrences of these newly restored 
>>> items. I have tried both "false" and "true" -o options, but neither 
>>> restores the original handle,  using this command.
>>> Might somebody correct me, please? (This handle has not need reassigned 
>>> in my existing db).
>>> 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/fd8ab807-4031-4626-af32-f9729025e31dn%40googlegroups.com.


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

2023-07-29 Thread Karol
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).  So, that large number of logs appears to be someone 
> > which is attempting to access those REST API endpoints without being 
> > authenticated.   Perhaps your login timed out while you were trying to 
> > run an export or import (from either the UI or REST API)?  Or, do you 
> > maybe have a custom script calling these export/import scripts which is 
> > failing to authenticate?  It also could be some sort of bot/crawler 
> > which is trying to crawl your REST API and stumbled on these endpoints. 
> >  It's really difficult to say for certain where the requests came from 
> > without more details about what you (or others) might have been doing at 
> > the time.
> > 
> > These are *not* errors in DSpace though. The 401 HTTP Code just means 
> > that someone tried to do something in DSpace which required 
> > authentication, and DSpace stopped them from doing it.
> > 
> > Tim
> > 
> > On Friday, July 28, 2023 at 7:57:07 AM UTC-5 karols...@gmail.com wrote:
> > 
> > Hi,
> > 
> > I'm back with a problem that is causing a large increase in logs. I
> > have a very large number of queries from my own server (api), I
> > can't find why this is happening. Can I ask for some guidance on how
> > to diagnose which process or user is generating these queries?
> > 
> > MyIP- - [28/Jul/2023:14:53:41 +0200] "GET
> > /server/api/system/scripts/metadata-export HTTP/1.1" 401 965 "-"
> > "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> > MyIP- - [28/Jul/2023:14:53:41 +0200] "GET
> > /server/api/system/scripts/metadata-import HTTP/1.1" 401 965 "-"
> > "Mozilla/5.0 (Linux x64) node.js/12.22.12 v8/7.8.279.23-node.57"
> > MyIP- - [28/Jul/2023:14:53:43 +0200] "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"
> > MyIP- - [28/Jul/2023:14:53:43 +0200] "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"
> > MyIP- - [28/Jul/2023:14:53:44 +0200] "GET
> >