Thanks. That's one of the things that I checked. It makes that much more frustrating when I can get to the file via the web or a service.
But this leads to a bigger question. My background is in big systems and I'm feeling my way around in the new world. I read in the section that Mr. Armintor kindly pointed out that it seems like a very bad idea to use file URI's for external datastreams. I'm am going to be using those extensively in the future and would appreciate it if anyone could suggest how I configure my server (or create the URI's) so that I can use an http based URI. This is at a level of ignorance so high that I would think that a reference to a web site or book would be the easiest way to answer. Thank you very much Rich -----Original Message----- From: aj...@virginia.edu [mailto:aj...@virginia.edu] Sent: Tuesday, November 29, 2011 12:57 PM To: Support and info exchange list for Fedora users. Subject: Re: [fcrepo-user] Ingest Question If I understand you rightly you are using the "Migrate" style of export, so that managed datastreams will be expressed in the exported FOXML as URLs back into the original repository. If, by any chance, the original repository URLs are inaccessible at the time of ingest (e.g., because of XACML policy), you may see some funny behavior. It's something that has bitten me before because of my own absent-mindedness and you might want to check to make sure it's not happening to you. It's easy to check by taking one of those URLs and retrieving it _from the machine on which the new repository is running_ right before you start the ingest, using a tool like 'wget' or 'curl'. If this fails, it should at least give you more information about why it's happening (whether you have an XACML policy problem or, like me, are a bit absentminded and prone to turning things off without remembering you did {grin}). --- A. Soroka Online Library Environment the University of Virginia Library > They are both using Akubra module. From the logs it appears that the object was not in low level storage. > > I did try using the export file directly as ingest. That seemed the most straight forward way to do this. However it refers to locations in the source repository for the managed datastreams and the ingest could not find them. That's why I tried changing to a file URL. > > I have not changed the policy file to allow this. Thank you very much this sounds promising. > > My other question relates to why I cannot ingest objects with managed datastreams directly from the original repository. > > My biggest problem is that Fedora comes with a huge set of concepts to digest all at once in support of it capabilities. Getting by that will be the challenge. > > Thank you > Rich > -----Original Message----- > From: Benjamin Armintor [mailto:armin...@gmail.com] > Sent: Tuesday, November 29, 2011 12:25 PM > To: Support and info exchange list for Fedora users. > Subject: Re: [fcrepo-user] Ingest Question > > Also, just in case: > https://wiki.duraspace.org/display/FEDORA35/Using+File+URIs > > On Tue, Nov 29, 2011 at 12:19 PM, Benjamin Armintor <armin...@gmail.com> wrote: >> Richard (the first): >> Can you provide a bit more detail about the configuration of the two >> fedoras (are they both using the same storage module?), what exactly >> it is you're trying to (it sounds like you're trying to submit the >> exported foxml as the body of an ingest request), and the type of 500 >> errors you're getting (or any information from the logs)? >> >> If you're changing the contentLocations to be file uris, did you also >> update the relevant policy to allow resolution of those uris? >> >> - Ben >> >> On Tue, Nov 29, 2011 at 12:00 PM, Richard Green <r.gr...@hull.ac.uk> wrote: >>> Rich >>> >>> >>> >>> Don't assume that it's just you. This sounds rather familiar and we've been >>> wondering if it was *us*. Are you trying this with the Fedora Java admin >>> client (ingest object(s) from repository)? If so - exactly what error >>> message do you get? What version of Fedora are you using? >>> >>> >>> >>> Richard >>> >>> ___________________________________________________________________ >>> >>> >>> >>> Richard Green >>> >>> Consultant to Library & Learning Innovation, University of Hull >>> >>> managing the History DMP and Hydra (Hull) Projects >>> >>> >>> >>> http://hydra.hull.ac.uk >>> >>> http://hydrangeainhull.wordpress.com >>> >>> http://projecthydra.org >>> >>> http://historydmp.wordpress.com >>> >>> >>> >>> >>> >>> >>> >>> From: Burgis, Richard [mailto:burgi...@ais.msu.edu] >>> Sent: 29 November 2011 4:04 PM >>> To: Support and info exchange list for Fedora users. >>> Subject: [fcrepo-user] Ingest Question >>> >>> >>> >>> I'm moving a test repository and trying various methods to get it to work. >>> >>> >>> >>> For objects with embedded content (X), I have no problem ingesting from the >>> source repository. But when I try ingesting objects with Managed content >>> (M), I get errors saying that the managed content cannot be found. >>> >>> >>> >>> I tried exporting the objects and ingesting the exported objects, but I get >>> the same result. >>> >>> >>> >>> I modified the contentLocation to use file URLs pointing to the location of >>> the content in the file system. This time the ingest succeeded, but I got >>> errors (500?) when I tried to edit or view the content. I got the same error >>> when I attempted to re-import it via the Admin program. I was finally able >>> to get the import to work after purging the items. >>> >>> >>> >>> This seems unreasonable as a process, so I would assume that I am missing >>> something critical. >>> >>> >>> >>> Any suggestions? >>> >>> Thanks >>> >>> Rich >>> >>> >>> >>> ------------------------------------------------------------------------ ------ >>> All the data continuously generated in your IT infrastructure >>> contains a definitive record of customers, application performance, >>> security threats, fraudulent activity, and more. Splunk takes this >>> data and makes sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-novd2d >>> _______________________________________________ >>> Fedora-commons-users mailing list >>> Fedora-commons-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users >>> >>> >> > > ------------------------------------------------------------------------ ------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > > ------------------------------------------------------------------------ ------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Fedora-commons-users mailing list > Fedora-commons-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------ ------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Fedora-commons-users mailing list Fedora-commons-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
