Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
Just as note to everyone. I've managed to merge the two instance and create the necessary handle in the DB. Thanks for the help everyone -Original Message- From: ivan.ma...@gmail.com [mailto:ivan.ma...@gmail.com] On Behalf Of helix84 Sent: Tuesday, 18 December 2012 6:58 PM To: George Rokkas Cc: dspace-tech Subject: Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations On Tue, Dec 18, 2012 at 8:53 AM, George Rokkas george.rok...@uts.edu.au wrote: I've got the dc.identifier.uri in the metadatavalue table which I planned to use to identify them What do u reakon ? Yes, it will work as you originally suggested, for any metadata value that's unique. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. Think. Green. Do. Please consider the environment before printing this email. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
I'm digging out an oldie. I've managed to migrate all our items to a single instance and I have to say that the -o ignorehandle doesn't work by importing the existing handles to the new instance, I assumed that the handle from the imported AIP would be created in the handle table, but it is not the case. I've contacted the hdladmin for the necessary changes, but I'm going to write a script to crawl the metadatavalue table to find all the old handles and then write the handle and resource_id to handle table. I think this should be a viable solution, what do you guys think? Cheers George -Original Message- From: George Rokkas [mailto:george.rok...@uts.edu.au] Sent: Friday, 31 August 2012 7:15 PM To: Tim Donohue Cc: DSpace Tech Subject: Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations Hey Tim, Thanks for the responses. I've previously completed steps 1, 2 and 3 successfully. I will look into the last step in having the redirect done at the handle.net. My concern is having the dspace instance answer for the 2100 handle requests. Does the handle server for that 10453 dspace instance need any tweaking aswell? Thanks again George -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Tuesday, 28 August 2012 12:55 AM To: George Rokkas Cc: DSpace Tech Subject: Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations Hi George, I could be mistaken here, but couldn't you just *keep* the old Handles alongside the new ones in the same DSpace instance? For example, I *believe* this will work (you may want to it out first, on a test server to be certain -- I've never tried this before). Use Case: Supposing you have two DSpace servers, configured with handle prefixes 2100 and 10453. You want to move all the 2100/* items over to the DSpace with handle prefix 10453. 1) First, export all 2100/* items from their DSpace using the AIP backup tools. https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore 2) Next, import those AIPs into the 10453 DSpace using the AIP restoration tools, but make sure to specify to *KEEP* the existing handles. For example: ./dspace packager -s -t AIP -e eperson -p collection-handle -o ignoreHandle=false Item-AIP.zip NOTICE: the ignoreHandle=false flag, which tells DSpace to *KEEP* the handle specified in the AIP. For more info see: https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore#AIPBackupandRestore-AdditionalPackagerOptions 3) At this point, you should have two different handle prefixes being used in the same DSpace. You'll have the 2100/* items which you moved over manually (via AIPs), and the DSpace itself will still be configured to use the 10453 handle prefix. 4) Finally, contact CNRI/Handle.net to let them know to point the 2100 handle prefix at the *same IP address* as your 10453 prefix. Essentially you'll now have two external handle prefixes pointing at the same DSpace instance. At this point, here's how I think things will work: * Requests via handle.net for 2100 handles will just get redirected to those new items in DSpace * Requests via handle.net for 10453 handles will just get redirected to those appropriate items in DSpace * New items/submissions into DSpace will always get assigned 10453 handles as that's the Handle server prefix (handle.prefix in dspace.cfg) configured within DSpace. The reason why this should work is that DSpace just stores handles in a database table (appropriately called handle). When you retrieve an item via its handle, it's just a simple database lookup to that table (the org.dspace.handle.HandleManager class does this). The actual handle.prefix configuration for DSpace is by default ONLY USED when generating new handles for brand new items/objects. I hope this helps! - Tim On 8/26/2012 9:49 PM, George Rokkas wrote: -Original Message- From: George Rokkas Sent: Monday, 27 August 2012 12:47 PM To: 'Scott Prater' Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: RE: [Handle-info] Dspace - Two Instances Migrations Hi Scott, Just reading http://www.elook.org/computing/rfc/rfc3651-21.html about HS_ALIAS This seems like a viable solution with the HS_ALIAS. Each handle would need its HS_ALIAS set to the new one, where does this happen? The Handle Server config file? Once the replication takes place, are you saying that you can switch off the 2100 Handle server as it will be no longer needed and the redirect will still take place? Thanks for your help George -Original Message- From: Scott Prater [mailto:pra...@wisc.edu] Sent: Saturday, 25 August 2012 12:22 AM To: George Rokkas Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: Re: [Handle-info] Dspace - Two Instances Migrations Hello, George, I don't know much about DSpace, but I can talk about some options in the handle server realm. You could simply add
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
Hi George, yes, you can do that (update the handle table) just fine. Afterwards, don't forget to run [dspace]/etc/postgres/update-sequences.sql But why do you need to crawl the metadatavalue table? If you already have handles or item_ids, you can just take them from the original handle table. What do you have that identifies the items? Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
Thanks helix84 But if I get the handles from the original table, don't I need to change the resource_id to match the new instance ? On 18/12/2012, at 6:42 PM, helix84 heli...@centrum.sk wrote: Hi George, yes, you can do that (update the handle table) just fine. Afterwards, don't forget to run [dspace]/etc/postgres/update-sequences.sql But why do you need to crawl the metadatavalue table? If you already have handles or item_ids, you can just take them from the original handle table. What do you have that identifies the items? Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. Think. Green. Do. Please consider the environment before printing this email. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
On Tue, Dec 18, 2012 at 8:49 AM, George Rokkas george.rok...@uts.edu.au wrote: But if I get the handles from the original table, don't I need to change the resource_id to match the new instance ? Yes, you're right, that wouldn't be so easy. So what do you have that identifies the items uniquely? Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
On Tue, Dec 18, 2012 at 8:53 AM, George Rokkas george.rok...@uts.edu.au wrote: I've got the dc.identifier.uri in the metadatavalue table which I planned to use to identify them What do u reakon ? Yes, it will work as you originally suggested, for any metadata value that's unique. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
George, As far as I can tell, I don't believe the DSpace Handle Server should need any tweaking. By default, as I mentioned, all the DSpace Handle Server code does is look up the associated handle in the 'handle' Database table. So, it should perform that lookup for both of your handle prefixes (2100 and 10453) and find the associated handles in that Database table. - Tim On 8/31/2012 4:15 AM, George Rokkas wrote: Hey Tim, Thanks for the responses. I've previously completed steps 1, 2 and 3 successfully. I will look into the last step in having the redirect done at the handle.net. My concern is having the dspace instance answer for the 2100 handle requests. Does the handle server for that 10453 dspace instance need any tweaking aswell? Thanks again George -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Tuesday, 28 August 2012 12:55 AM To: George Rokkas Cc: DSpace Tech Subject: Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations Hi George, I could be mistaken here, but couldn't you just *keep* the old Handles alongside the new ones in the same DSpace instance? For example, I *believe* this will work (you may want to it out first, on a test server to be certain -- I've never tried this before). Use Case: Supposing you have two DSpace servers, configured with handle prefixes 2100 and 10453. You want to move all the 2100/* items over to the DSpace with handle prefix 10453. 1) First, export all 2100/* items from their DSpace using the AIP backup tools. https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore 2) Next, import those AIPs into the 10453 DSpace using the AIP restoration tools, but make sure to specify to *KEEP* the existing handles. For example: ./dspace packager -s -t AIP -e eperson -p collection-handle -o ignoreHandle=false Item-AIP.zip NOTICE: the ignoreHandle=false flag, which tells DSpace to *KEEP* the handle specified in the AIP. For more info see: https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore#AIPBackupandRestore-AdditionalPackagerOptions 3) At this point, you should have two different handle prefixes being used in the same DSpace. You'll have the 2100/* items which you moved over manually (via AIPs), and the DSpace itself will still be configured to use the 10453 handle prefix. 4) Finally, contact CNRI/Handle.net to let them know to point the 2100 handle prefix at the *same IP address* as your 10453 prefix. Essentially you'll now have two external handle prefixes pointing at the same DSpace instance. At this point, here's how I think things will work: * Requests via handle.net for 2100 handles will just get redirected to those new items in DSpace * Requests via handle.net for 10453 handles will just get redirected to those appropriate items in DSpace * New items/submissions into DSpace will always get assigned 10453 handles as that's the Handle server prefix (handle.prefix in dspace.cfg) configured within DSpace. The reason why this should work is that DSpace just stores handles in a database table (appropriately called handle). When you retrieve an item via its handle, it's just a simple database lookup to that table (the org.dspace.handle.HandleManager class does this). The actual handle.prefix configuration for DSpace is by default ONLY USED when generating new handles for brand new items/objects. I hope this helps! - Tim On 8/26/2012 9:49 PM, George Rokkas wrote: -Original Message- From: George Rokkas Sent: Monday, 27 August 2012 12:47 PM To: 'Scott Prater' Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: RE: [Handle-info] Dspace - Two Instances Migrations Hi Scott, Just reading http://www.elook.org/computing/rfc/rfc3651-21.html about HS_ALIAS This seems like a viable solution with the HS_ALIAS. Each handle would need its HS_ALIAS set to the new one, where does this happen? The Handle Server config file? Once the replication takes place, are you saying that you can switch off the 2100 Handle server as it will be no longer needed and the redirect will still take place? Thanks for your help George -Original Message- From: Scott Prater [mailto:pra...@wisc.edu] Sent: Saturday, 25 August 2012 12:22 AM To: George Rokkas Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: Re: [Handle-info] Dspace - Two Instances Migrations Hello, George, I don't know much about DSpace, but I can talk about some options in the handle server realm. You could simply add HS_ALIAS values to your old handles, pointing to the new handles: then the handle server should redirect. Is it a requirement that the migrated handles have new IDs? If the goal is simply to migrate the handles, and maintaining the IDs is an option, you could set up your new handle server as a mirror of the current one, let the replication happen
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
Hey Tim, Thanks for the responses. I've previously completed steps 1, 2 and 3 successfully. I will look into the last step in having the redirect done at the handle.net. My concern is having the dspace instance answer for the 2100 handle requests. Does the handle server for that 10453 dspace instance need any tweaking aswell? Thanks again George -Original Message- From: Tim Donohue [mailto:tdono...@duraspace.org] Sent: Tuesday, 28 August 2012 12:55 AM To: George Rokkas Cc: DSpace Tech Subject: Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations Hi George, I could be mistaken here, but couldn't you just *keep* the old Handles alongside the new ones in the same DSpace instance? For example, I *believe* this will work (you may want to it out first, on a test server to be certain -- I've never tried this before). Use Case: Supposing you have two DSpace servers, configured with handle prefixes 2100 and 10453. You want to move all the 2100/* items over to the DSpace with handle prefix 10453. 1) First, export all 2100/* items from their DSpace using the AIP backup tools. https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore 2) Next, import those AIPs into the 10453 DSpace using the AIP restoration tools, but make sure to specify to *KEEP* the existing handles. For example: ./dspace packager -s -t AIP -e eperson -p collection-handle -o ignoreHandle=false Item-AIP.zip NOTICE: the ignoreHandle=false flag, which tells DSpace to *KEEP* the handle specified in the AIP. For more info see: https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore#AIPBackupandRestore-AdditionalPackagerOptions 3) At this point, you should have two different handle prefixes being used in the same DSpace. You'll have the 2100/* items which you moved over manually (via AIPs), and the DSpace itself will still be configured to use the 10453 handle prefix. 4) Finally, contact CNRI/Handle.net to let them know to point the 2100 handle prefix at the *same IP address* as your 10453 prefix. Essentially you'll now have two external handle prefixes pointing at the same DSpace instance. At this point, here's how I think things will work: * Requests via handle.net for 2100 handles will just get redirected to those new items in DSpace * Requests via handle.net for 10453 handles will just get redirected to those appropriate items in DSpace * New items/submissions into DSpace will always get assigned 10453 handles as that's the Handle server prefix (handle.prefix in dspace.cfg) configured within DSpace. The reason why this should work is that DSpace just stores handles in a database table (appropriately called handle). When you retrieve an item via its handle, it's just a simple database lookup to that table (the org.dspace.handle.HandleManager class does this). The actual handle.prefix configuration for DSpace is by default ONLY USED when generating new handles for brand new items/objects. I hope this helps! - Tim On 8/26/2012 9:49 PM, George Rokkas wrote: -Original Message- From: George Rokkas Sent: Monday, 27 August 2012 12:47 PM To: 'Scott Prater' Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: RE: [Handle-info] Dspace - Two Instances Migrations Hi Scott, Just reading http://www.elook.org/computing/rfc/rfc3651-21.html about HS_ALIAS This seems like a viable solution with the HS_ALIAS. Each handle would need its HS_ALIAS set to the new one, where does this happen? The Handle Server config file? Once the replication takes place, are you saying that you can switch off the 2100 Handle server as it will be no longer needed and the redirect will still take place? Thanks for your help George -Original Message- From: Scott Prater [mailto:pra...@wisc.edu] Sent: Saturday, 25 August 2012 12:22 AM To: George Rokkas Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: Re: [Handle-info] Dspace - Two Instances Migrations Hello, George, I don't know much about DSpace, but I can talk about some options in the handle server realm. You could simply add HS_ALIAS values to your old handles, pointing to the new handles: then the handle server should redirect. Is it a requirement that the migrated handles have new IDs? If the goal is simply to migrate the handles, and maintaining the IDs is an option, you could set up your new handle server as a mirror of the current one, let the replication happen, then break the mirror and turn off the old server. -- Scott On 08/24/2012 02:39 AM, George Rokkas wrote: Hi Bram, Thanks for the reply. 1.It's a permanent move 2.Yes both their own handle servers: 2100 and 10453 3.It will be shut down, I was planning on bringing the shutdown handle across to the second repo. Thanks George *From:*bluy...@gmail.com [mailto:bluy...@gmail.com] *On Behalf Of *Bram Luyten *Sent:* Friday, 24 August 2012 5:20 PM *To:* George
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
Hi George, I could be mistaken here, but couldn't you just *keep* the old Handles alongside the new ones in the same DSpace instance? For example, I *believe* this will work (you may want to it out first, on a test server to be certain -- I've never tried this before). Use Case: Supposing you have two DSpace servers, configured with handle prefixes 2100 and 10453. You want to move all the 2100/* items over to the DSpace with handle prefix 10453. 1) First, export all 2100/* items from their DSpace using the AIP backup tools. https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore 2) Next, import those AIPs into the 10453 DSpace using the AIP restoration tools, but make sure to specify to *KEEP* the existing handles. For example: ./dspace packager -s -t AIP -e eperson -p collection-handle -o ignoreHandle=false Item-AIP.zip NOTICE: the ignoreHandle=false flag, which tells DSpace to *KEEP* the handle specified in the AIP. For more info see: https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore#AIPBackupandRestore-AdditionalPackagerOptions 3) At this point, you should have two different handle prefixes being used in the same DSpace. You'll have the 2100/* items which you moved over manually (via AIPs), and the DSpace itself will still be configured to use the 10453 handle prefix. 4) Finally, contact CNRI/Handle.net to let them know to point the 2100 handle prefix at the *same IP address* as your 10453 prefix. Essentially you'll now have two external handle prefixes pointing at the same DSpace instance. At this point, here's how I think things will work: * Requests via handle.net for 2100 handles will just get redirected to those new items in DSpace * Requests via handle.net for 10453 handles will just get redirected to those appropriate items in DSpace * New items/submissions into DSpace will always get assigned 10453 handles as that's the Handle server prefix (handle.prefix in dspace.cfg) configured within DSpace. The reason why this should work is that DSpace just stores handles in a database table (appropriately called handle). When you retrieve an item via its handle, it's just a simple database lookup to that table (the org.dspace.handle.HandleManager class does this). The actual handle.prefix configuration for DSpace is by default ONLY USED when generating new handles for brand new items/objects. I hope this helps! - Tim On 8/26/2012 9:49 PM, George Rokkas wrote: -Original Message- From: George Rokkas Sent: Monday, 27 August 2012 12:47 PM To: 'Scott Prater' Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: RE: [Handle-info] Dspace - Two Instances Migrations Hi Scott, Just reading http://www.elook.org/computing/rfc/rfc3651-21.html about HS_ALIAS This seems like a viable solution with the HS_ALIAS. Each handle would need its HS_ALIAS set to the new one, where does this happen? The Handle Server config file? Once the replication takes place, are you saying that you can switch off the 2100 Handle server as it will be no longer needed and the redirect will still take place? Thanks for your help George -Original Message- From: Scott Prater [mailto:pra...@wisc.edu] Sent: Saturday, 25 August 2012 12:22 AM To: George Rokkas Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: Re: [Handle-info] Dspace - Two Instances Migrations Hello, George, I don't know much about DSpace, but I can talk about some options in the handle server realm. You could simply add HS_ALIAS values to your old handles, pointing to the new handles: then the handle server should redirect. Is it a requirement that the migrated handles have new IDs? If the goal is simply to migrate the handles, and maintaining the IDs is an option, you could set up your new handle server as a mirror of the current one, let the replication happen, then break the mirror and turn off the old server. -- Scott On 08/24/2012 02:39 AM, George Rokkas wrote: Hi Bram, Thanks for the reply. 1.It's a permanent move 2.Yes both their own handle servers: 2100 and 10453 3.It will be shut down, I was planning on bringing the shutdown handle across to the second repo. Thanks George *From:*bluy...@gmail.com [mailto:bluy...@gmail.com] *On Behalf Of *Bram Luyten *Sent:* Friday, 24 August 2012 5:20 PM *To:* George Rokkas *Cc:* handle-i...@cnri.reston.va.us; DSpace Tech *Subject:* Re: [Handle-info] Dspace - Two Instances Migrations Hi George, a few questions to make sure I totally understand what you're trying to accomplish: - you're trying to permanently move these items from one DSpace to another, right? - Are both DSpace installations running their own handle server? - Do you have any items left in the first repository, after this migration? e.g. will you keep using two handle prefixes in the end situation? Also copying your email to the DSpace-Tech mailing list. In case
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
One final note. I forgot to mention, obviously the below solution would not work unless you are moving *ALL ITEMS* with prefix 2100 over to the DSpace with prefix 10453. If you only wanted to move a few of the 2100/* items, then the below solution would definitely NOT work, as you would be switching the 2100 prefix to point to a completely different location (IP address). - Tim On 8/27/2012 9:55 AM, Tim Donohue wrote: Hi George, I could be mistaken here, but couldn't you just *keep* the old Handles alongside the new ones in the same DSpace instance? For example, I *believe* this will work (you may want to it out first, on a test server to be certain -- I've never tried this before). Use Case: Supposing you have two DSpace servers, configured with handle prefixes 2100 and 10453. You want to move all the 2100/* items over to the DSpace with handle prefix 10453. 1) First, export all 2100/* items from their DSpace using the AIP backup tools. https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore 2) Next, import those AIPs into the 10453 DSpace using the AIP restoration tools, but make sure to specify to *KEEP* the existing handles. For example: ./dspace packager -s -t AIP -e eperson -p collection-handle -o ignoreHandle=false Item-AIP.zip NOTICE: the ignoreHandle=false flag, which tells DSpace to *KEEP* the handle specified in the AIP. For more info see: https://wiki.duraspace.org/display/DSDOC18/AIP+Backup+and+Restore#AIPBackupandRestore-AdditionalPackagerOptions 3) At this point, you should have two different handle prefixes being used in the same DSpace. You'll have the 2100/* items which you moved over manually (via AIPs), and the DSpace itself will still be configured to use the 10453 handle prefix. 4) Finally, contact CNRI/Handle.net to let them know to point the 2100 handle prefix at the *same IP address* as your 10453 prefix. Essentially you'll now have two external handle prefixes pointing at the same DSpace instance. At this point, here's how I think things will work: * Requests via handle.net for 2100 handles will just get redirected to those new items in DSpace * Requests via handle.net for 10453 handles will just get redirected to those appropriate items in DSpace * New items/submissions into DSpace will always get assigned 10453 handles as that's the Handle server prefix (handle.prefix in dspace.cfg) configured within DSpace. The reason why this should work is that DSpace just stores handles in a database table (appropriately called handle). When you retrieve an item via its handle, it's just a simple database lookup to that table (the org.dspace.handle.HandleManager class does this). The actual handle.prefix configuration for DSpace is by default ONLY USED when generating new handles for brand new items/objects. I hope this helps! - Tim On 8/26/2012 9:49 PM, George Rokkas wrote: -Original Message- From: George Rokkas Sent: Monday, 27 August 2012 12:47 PM To: 'Scott Prater' Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: RE: [Handle-info] Dspace - Two Instances Migrations Hi Scott, Just reading http://www.elook.org/computing/rfc/rfc3651-21.html about HS_ALIAS This seems like a viable solution with the HS_ALIAS. Each handle would need its HS_ALIAS set to the new one, where does this happen? The Handle Server config file? Once the replication takes place, are you saying that you can switch off the 2100 Handle server as it will be no longer needed and the redirect will still take place? Thanks for your help George -Original Message- From: Scott Prater [mailto:pra...@wisc.edu] Sent: Saturday, 25 August 2012 12:22 AM To: George Rokkas Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: Re: [Handle-info] Dspace - Two Instances Migrations Hello, George, I don't know much about DSpace, but I can talk about some options in the handle server realm. You could simply add HS_ALIAS values to your old handles, pointing to the new handles: then the handle server should redirect. Is it a requirement that the migrated handles have new IDs? If the goal is simply to migrate the handles, and maintaining the IDs is an option, you could set up your new handle server as a mirror of the current one, let the replication happen, then break the mirror and turn off the old server. -- Scott On 08/24/2012 02:39 AM, George Rokkas wrote: Hi Bram, Thanks for the reply. 1.It's a permanent move 2.Yes both their own handle servers: 2100 and 10453 3.It will be shut down, I was planning on bringing the shutdown handle across to the second repo. Thanks George *From:*bluy...@gmail.com [mailto:bluy...@gmail.com] *On Behalf Of *Bram Luyten *Sent:* Friday, 24 August 2012 5:20 PM *To:* George Rokkas *Cc:* handle-i...@cnri.reston.va.us; DSpace Tech *Subject:* Re: [Handle-info] Dspace - Two Instances Migrations Hi George, a few
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
-Original Message- From: George Rokkas Sent: Monday, 27 August 2012 12:47 PM To: 'Scott Prater' Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: RE: [Handle-info] Dspace - Two Instances Migrations Hi Scott, Just reading http://www.elook.org/computing/rfc/rfc3651-21.html about HS_ALIAS This seems like a viable solution with the HS_ALIAS. Each handle would need its HS_ALIAS set to the new one, where does this happen? The Handle Server config file? Once the replication takes place, are you saying that you can switch off the 2100 Handle server as it will be no longer needed and the redirect will still take place? Thanks for your help George -Original Message- From: Scott Prater [mailto:pra...@wisc.edu] Sent: Saturday, 25 August 2012 12:22 AM To: George Rokkas Cc: Bram Luyten; handle-i...@cnri.reston.va.us; DSpace Tech Subject: Re: [Handle-info] Dspace - Two Instances Migrations Hello, George, I don't know much about DSpace, but I can talk about some options in the handle server realm. You could simply add HS_ALIAS values to your old handles, pointing to the new handles: then the handle server should redirect. Is it a requirement that the migrated handles have new IDs? If the goal is simply to migrate the handles, and maintaining the IDs is an option, you could set up your new handle server as a mirror of the current one, let the replication happen, then break the mirror and turn off the old server. -- Scott On 08/24/2012 02:39 AM, George Rokkas wrote: Hi Bram, Thanks for the reply. 1.It's a permanent move 2.Yes both their own handle servers: 2100 and 10453 3.It will be shut down, I was planning on bringing the shutdown handle across to the second repo. Thanks George *From:*bluy...@gmail.com [mailto:bluy...@gmail.com] *On Behalf Of *Bram Luyten *Sent:* Friday, 24 August 2012 5:20 PM *To:* George Rokkas *Cc:* handle-i...@cnri.reston.va.us; DSpace Tech *Subject:* Re: [Handle-info] Dspace - Two Instances Migrations Hi George, a few questions to make sure I totally understand what you're trying to accomplish: - you're trying to permanently move these items from one DSpace to another, right? - Are both DSpace installations running their own handle server? - Do you have any items left in the first repository, after this migration? e.g. will you keep using two handle prefixes in the end situation? Also copying your email to the DSpace-Tech mailing list. In case you're not subscribed there, you can find the info here: https://lists.sourceforge.net/lists/listinfo/dspace-tech best regards, Bram Luyten -- logo *Bram Luyten*/@mire/ /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/ /Esperantolaan 4, Heverlee 3001, Belgium/ http://www.atmire.com/www.atmire.com http://atmire.com/website/?q=servicesutm_source=emailfooterutm_medi um=emailutm_campaign=braml On Fri, Aug 24, 2012 at 4:44 AM, George Rokkas george.rok...@uts.edu.au mailto:george.rok...@uts.edu.au wrote: Hey All, I'm new around here. I'm George and I'm the systems architect at University of Technology, Sydney Library. We currently have two Dspace instances running side by side and we want to bring 900 items from instance1 to instance 2. We've managed to work out how to do this via AIP export and import which assigns each item with a new handle. What I'm trying to find out is that if an item had the handle /2100/803 and now has /10453/17883. Can I get the original handle to redirect to the new one without having to do a redirect at the web server level. I'm really appreciative of any help I could get. Thank You George Rokkas UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. Think. Green. Do. Please consider the environment before printing this email. UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology
Re: [Dspace-tech] [Handle-info] Dspace - Two Instances Migrations
Hi George, a few questions to make sure I totally understand what you're trying to accomplish: - you're trying to permanently move these items from one DSpace to another, right? - Are both DSpace installations running their own handle server? - Do you have any items left in the first repository, after this migration? e.g. will you keep using two handle prefixes in the end situation? Also copying your email to the DSpace-Tech mailing list. In case you're not subscribed there, you can find the info here: https://lists.sourceforge.net/lists/listinfo/dspace-tech best regards, Bram Luyten -- [image: logo] *Bram Luyten* *@mire* *2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010* *Esperantolaan 4, Heverlee 3001, Belgium* http://www.atmire.com/www.atmire.comhttp://atmire.com/website/?q=servicesutm_source=emailfooterutm_medium=emailutm_campaign=braml On Fri, Aug 24, 2012 at 4:44 AM, George Rokkas george.rok...@uts.edu.auwrote: Hey All, ** ** I’m new around here. I’m George and I’m the systems architect at University of Technology, Sydney Library. ** ** We currently have two Dspace instances running side by side and we want to bring 900 items from instance1 to instance 2. We’ve managed to work out how to do this via AIP export and import which assigns each item with a new handle. What I’m trying to find out is that if an item had the handle /2100/803 and now has /10453/17883. Can I get the original handle to redirect to the new one without having to do a redirect at the web server level. ** ** I’m really appreciative of any help I could get. ** ** Thank You ** ** George Rokkas ** ** ** ** UTS CRICOS Provider Code: 00099F DISCLAIMER: This email message and any accompanying attachments may contain confidential information. If you are not the intended recipient, do not read, use, disseminate, distribute or copy this message or attachments. If you have received this message in error, please notify the sender immediately and delete this message. Any views expressed in this message are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of the University of Technology Sydney. Before opening any attachments, please check them for viruses and defects. Think. Green. Do. Please consider the environment before printing this email. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
