Here's a different option (that I used to use at Illinois): (1) Before migration day, notify handle.net folks that you will be moving to a new server. Ask them nicely if they can update your handle prefix settings for you on that migration day (you'll need to send an updated sitebndl.zip before or on that day, generated from the new server, using the new IP).
(2) On migration day, move DSpace over to the new server. A handle server is bundled with DSpace already (which uses the internal DSpace DB to lookup handles). (3) Notify handle.net folks to switch over the handle prefix to your new IP (4) Reconfigure the new server's dspace.cfg with your existing handle prefix. (5) Startup DSpace on the new server. As soon as the handle.net folks switch your prefix to the new IP, the DSpace handle server (on your new server) will start receiving requests and start working. Does that make sense? I'm wondering if you even need to keep the handle server on the old server at all -- it sounds like that'd just make things more complex. - Tim On 6/11/2010 1:21 PM, Wendy J Bossons wrote: > Essentially then, and to hopefully accurately paraphrase Mark W.'s comments . > . . > > If the server where dsp...@mit currently resides continues to run, and if we > continue using the same database location, then the handle-server should run. > However, if we move the database to a new location, then the handle-server > needs to be configured to use the new location... How is that done, > reconfiguring the handle-server to use a new location? -- is it the simple > setup of the new handle server and notification to CNRI, or is there > something on the dspace application side besides the handle.dir? > > Also, why would I have to update the old installation -- we will be retiring > that? Again, pardon my newbiness . . . I haven't set up the handle-server > prior to this. > > Thanks! > > > ..\Wendy > Wendy Bossons > Web Developer > MIT Libraries > Technology Research and Development > 77 Masachusetts Avenue > Cambridge, MA 02139-4307 > 617-253-0770 > wboss...@mit.edu > > On Jun 11, 2010, at 2:07 PM, Mark Diggory mdigg...@atmire.com wrote: > >> The handle server uses the HandleManager as a plugin to bridge the dspace >> database into the handle service. The Handle Server doesn't store handles >> internally. Its all in the postgres db at the moment. >> >> Mark >> >> On Jun 11, 2010, at 11:00 AM, Wendy J Bossons wrote: >> >>> With respect to the live database, do you mean the dsp...@mit production >>> database or a flat file database that, perhaps, the handle-server uses? If >>> the latter, how would I configure this? (I am not familiar with the running >>> of the handle-server yet, so I am not sure how all the pieces fit together. >>> Any simple elaboration would be helpful. ) Thanks! >>> >>> ..\Wendy >>> >>> >>> ..\Wendy >>> Wendy Bossons >>> Web Developer >>> MIT Libraries >>> Technology Research and Development >>> 77 Masachusetts Avenue >>> Cambridge, MA 02139-4307 >>> 617-253-0770 >>> wboss...@mit.edu >>> >>> On Jun 11, 2010, at 1:27 PM, Mark H. Wood wrote: >>> >>>> The only parts of the installation that care about location seem to be >>>> bin/start-handle-server and the HandlePlugin class that interfaces the >>>> Handle server to DSpace's database. I presume that you're leaving the >>>> old DSpace installation in place (perhaps not running any UI) until you >>>> complete the migration. >>>> >>>> If the live database does not move, then I would expect the Handle >>>> server to continue working. If you *do* move the database, you will >>>> need to configure both the new *and* the old installations to use the >>>> new location and then restart the Handle server. >>>> >>>> I have *not* tried this. Please test carefully before committing to >>>> anything. >>>> >>>> -- >>>> Mark H. Wood, Lead System Programmer mw...@iupui.edu >>>> Balance your desire for bells and whistles with the reality that only a >>>> little more than 2 percent of world population has broadband. >>>> -- Ledford and Tyler, _Google Analytics 2.0_ >>>> <ATT00001><ATT00002.c><ATT00003.c> >>> >>> >>> ------------------------------------------------------------------------------ >>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>> lucky parental unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> _______________________________________________ >>> Dspace-devel mailing list >>> Dspace-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/dspace-devel >> > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Dspace-devel mailing list > Dspace-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-devel ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
