Hello, Am 01.02.2013 um 17:54 schrieb "Cronin, Catherine Kemble (LARC-B702)" <catherine.k.cro...@nasa.gov>:
> > We have set up and configured a development instance of dspace 1.8 (jspui) > that has been tested and approved to go into production. > What is the best practice for copying a fully customized and configured > instance of dspace over to a new server for each of the following cases? > > 1. Instance including all of the content (ie bitstreams) – basically a > full replication from one server to another. > 2. Instance including no items or bitstreams, but all of the > Communities and Collections. Basically the “structure” without items. I guess, the latter case is hard to accomplish, I have no idea for this. And as long as there are not hundreds of communities I dont even think it is a good idea. I would use a clean copy and enter the Communities and Collections from scratch. Both cases imply that it will happen only once in a lifetime and that the test environment has turned into a production environment during testing already. It wont make sense to take over items from testing to production any time after the initial setup. Or to say it differently, for further development you should consider to keep data completely separate from the production environment. If you keep data separate and dont want to set up all the stuff required to compile DSpace in your production environment, you can copy over the webapps directory content as required, id est certainly the jspui directory, but other, such as lni or oai depending on whether you will use them at all. If you go deeply into the code, then there will be new versions of some .jar files in the lib directory, specifically dspace.jar you will have to copy over as well. If copying webapps and .jar files manually to the production server, you will have to tweak your config files in the dspace/config directory manually. This should not be too hard to do, they are rarely changed after initial setup. To get started (your case one), you will have to copy over the whole [dspace] directory including the assetstore, config and so on. I would use rsync for this purpose. You can clean out log, history, reports and so on and you can remove the etc subdirectory, but working directories like log, history and so on need to be in the place indicated in your [dspace]/config/dspace.cfg file and writeable for the tomcat user. Besides the [dspace] directory, you will need to dump your postgres database and load it into the production environment. Consider not using dump_all, but to dump the dspace database only. Take care of preserving oids during the transfer of the database. After you have done so, you have to move the webapps stuff as well as described before if you keep your webapps in a place different from your [dspace] directory. Check the DSpace install steps to find any steps missing in my short advisory. For me, it has turned out to be a suitable solution to set up a new machine when it comes to a new DSpace version. I do all my testing on this machine, then move over essentially the assetstore and the database. I then have to run the etc files to update the database to the current version and after a short test I am ready to switch over the DNS entry. The old machine gets to be my testing environment for further development. This way, I have a full DSpace compilation environment on my production machine and can apply small changes without the help of another machine. It is up to me to be conscious and not to apply larger changes on the production machine. Bye, Christian ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ 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
