Yes, I think you'd have to turn off the API-A authentication requirement, and then implement a policy somewhat like that disallowing API-M from non-localhost servers (for API-A and with an exception, of course).
On Fri, Dec 2, 2011 at 11:03 AM, Stephen Bayliss <stephen.bayl...@acuityunlimited.net> wrote: > Hi Scott > > It might be a solution... but won't the authN challenge still happen if > API-A authentication is turned on? Won't the policy just define authZ, ie > whether the request is allowed, rather than whether the request has to be > authenticated? > > Steve > >> -----Original Message----- >> From: Scott Prater [mailto:pra...@wisc.edu] >> Sent: Friday, December 02, 2011 1:59 PM >> To: Support and info exchange list for Fedora users. >> Subject: Re: [fcrepo-user] Ingest Question >> >> Would IP-based FeSL authentication and an IP access rule in a global XACML >> policy be a good temporary workaround for this problem? That is, allowing >> on the sourcerepo unauthenticated access from the target repo, and setting >> a corresponding rule that opens the door to the target IP in a global >> XACML policy on the source server? >> >> That would basically mean any requests from the target server to the >> source server would be allowed in, but I suppose the XACML could be >> tightened to just apply to certain objects or operations, if that were >> necessary. >> >> -- Scott >> >> On 12/02/11, Stephen Bayliss wrote: >> > > However, as the Fedora admin client has had to authenticate in order >> to >> > > get the FOXML export from the source, I'd have imagined that those >> > > credentials were around to use when fetching any managed datastreams >> > > that the subsequent ingest needed? >> > >> > I think this is the issue - the Admin client has the credentials, and >> uses >> > these to generate the FOXML to pass to the target server. But the >> target >> > server doesn't have credentials to use when getting the datastream. >> > >> > >> > > We've just thought to check the >> > > source server log for a matching 401: the only thing in the fedora- >> prod >> > > logs is a INFO line saying that 'Completed Export..(pid:4994... >> Nothing >> > > else is reported. >> > >> > That would make sense I think - it is essentially a two-phase process >> > - generating FOXML that has references to the datastream location on the >> > source server >> > - ingesting that FOXML on the target server, at which point the >> datastreams >> > are grabbed >> > >> > So possibly you can see some 401 errors later down? >> > >> > Steve >> > >> > >> > > -----Original Message----- >> > > From: Richard Green >> [mailto:r.gr...@hull.ac.uk](javascript:main.compose() >> > > Sent: Friday, December 02, 2011 1:16 PM >> > > To: Support and info exchange list for Fedora users. >> > > Subject: Re: [fcrepo-user] Ingest Question >> > > >> > > Our test and production servers have authentication enabled for API-A >> > > and API-M access so it's not a locally added XACML policy, if that's >> > > what you meant Adam. >> > > >> > > However, as the Fedora admin client has had to authenticate in order >> to >> > > get the FOXML export from the source, I'd have imagined that those >> > > credentials were around to use when fetching any managed datastreams >> > > that the subsequent ingest needed? We've just thought to check the >> > > source server log for a matching 401: the only thing in the fedora- >> prod >> > > logs is a INFO line saying that 'Completed Export..(pid:4994... >> Nothing >> > > else is reported. >> > > >> > > Richard >> > > >> > > -----Original Message----- >> > > From: aj...@virginia.edu >> [mailto:aj...@virginia.edu](javascript:main.compose() >> > > Sent: 02 December 2011 12:50 PM >> > > To: Support and info exchange list for Fedora users. >> > > Subject: Re: [fcrepo-user] Ingest Question >> > > >> > > So I understand rightly, this object has managed datastreams that are >> > > guarded by XACML policies that do not allow for unauthenticated >> access. >> > > The receiving repo has no way to authenticate, and therefore cannot >> > > obtain the datastreams. Is that right? >> > > >> > > --- >> > > A. Soroka >> > > Online Library Environment >> > > the University of Virginia Library >> > > >> > > >> > > >> > > >> > > On Dec 2, 2011, at 8:24 AM, Stephen Bayliss wrote: >> > > >> > > > Hi Richard >> > > > >> > > > I think your non-developer eye may have spotted the issue here. >> > > > >> > > > The doCommit(...) method is where the object is being saved on the >> > > > target server, and that's the point at which it is using a URL (from >> > > > the FOXML) to grab the content from the managed content datastream >> > > > from the origin server so it can save the datastream. >> > > > >> > > > And it would appear that it is not authenticating (and therefore >> > > > getting a >> > > > 401) when it is attempting to grab the content. In fact I don't >> think >> > > >> > > > the target server would have the credentials at that point. And I >> am >> > > > struggling to think as to what the best resolution for this might >> > > be... >> > > > >> > > > Steve >> > > > >> > > > -----Original Message----- >> > > > From: Richard Green >> [mailto:r.gr...@hull.ac.uk](javascript:main.compose() >> > > > Sent: Friday, December 02, 2011 10:34 AM >> > > > To: Support and info exchange list for Fedora users. >> > > > Subject: Re: [fcrepo-user] Ingest Question >> > > > >> > > > You're right, Steve, that was the client log. Attached the much >> > > > longer server log entry (I've edited a URL or two for security). >> > > > Although we recreated the problem this morning it follows the exact >> > > > pattern described below. FYI the object was hull:4994, comprising >> > > > five metadata-only datastreams DC (X), descMetadata (M), RELS-EXT >> (X), >> > > >> > > > rightsMetadata (X), defaultObjectRights (X). It does seem to be >> > > > managed datastreams that cause the problem. Note the final >> 'causedBy' >> > > >> > > > 401 - to my non-developer eye it makes me wonder if maybe >> credentials >> > > > aren't getting passed to the source server (despite the fact the >> admin >> > > >> > > > client has credentials for both source and destination). >> > > > >> > > > Richard >> > > > >> > > > -----Original Message----- >> > > > From: Stephen Bayliss >> [mailto:stephen.bayl...@acuityunlimited.net](javascript:main.compose() >> > > > Sent: 01 December 2011 6:15 PM >> > > > To: 'Support and info exchange list for Fedora users.' >> > > > Subject: Re: [fcrepo-user] Ingest Question >> > > > >> > > > Hi Richard >> > > > >> > > > This looks like the error/stack trace from the Java client >> (apologies >> > > > if I am mistaken) - if that is the case can you find the relevant >> > > > section of the receiving server's log file and see if it provides >> any >> > > > more detail. >> > > > >> > > > Thanks >> > > > Steve >> > > > >> > > > -----Original Message----- >> > > > From: Richard Green >> [mailto:r.gr...@hull.ac.uk](javascript:main.compose() >> > > > Sent: Thursday, December 01, 2011 10:51 AM >> > > > To: Support and info exchange list for Fedora users. >> > > > Subject: Re: [fcrepo-user] Ingest Question >> > > > >> > > > So, Adam (and others), it goes like this: >> > > > >> > > > We have two properly configured Fedora 3.4 servers, 'test' and >> 'prod'. >> > > > By that I mean the fcfg file has a proper address for the server, >> not >> > > > just 'localhost'. >> > > > >> > > > If, on my desktop machine's Fedora Java admin client, I log into >> test >> > > > and try to do 'ingest > one object > from repository' from prod >> > > > (giving correct passwords and asking for 'migrate' format) I get an >> > > > 'HttpServiceNotFoundException' (full error listing below) for a >> > > > metadata-only object (this for a 'managed' metadata datastream). >> > > > >> > > > If we use the admin client software actually on the test server, the >> > > > exact same thing. If we use a browser on the test server to access >> > > > http://....../fedora/search on prod and attempt to download the >> > > > failing datastream or file from there - it works fine (which makes >> us >> > > > think it isn't a firewall thing). >> > > > >> > > > The log on the sending server (prod) reports a successful export. >> > > > >> > > > If the attempted ingest involves a content datastream (which, for us >> > > > means an MD5 checksum is set), we get a checksum failure rather than >> > > > an HttpService error, but I'd like to bet that the checksum failure >> is >> > > >> > > > actually because the file can't be retrieved. >> > > > >> > > > 'Prod' really is our repository production server so we know that >> > > > we're starting with valid objects. The httpService error stack is >> > > > below (I've just removed part of the server address for security). >> If >> > > >> > > > I paste the full address from the error message into a browser I get >> > > > an authentication challenge and then the datastream content. (That >> > > > won't work for you because the Fedora server is behind the >> University >> > > > firewall.) >> > > > >> > > > When we set up the prod server 10 weeks ago we tried to transfer >> > > > content in the reverse direction (test to prod) but failed (we ended >> > > > up copying the data directories and (re)building prod's Fedora over >> > > > them - probably quicker anyway). I can't now swear we got the exact >> > > > same error, but I'd be fairly certain. I'm very reluctant to try a >> > > > 'test to prod' transfer now, precisely because it is the production >> > > server we're dealing with. >> > > > >> > > > Any insights welcome!!! >> > > > >> > > > ================================= >> > > > >> > > > org.fcrepo.server.errors.HttpServiceNotFoundException: >> > > > [DefaultExternalContentManager] returned an error. The underlying >> > > > error was a org.fcrepo .server.errors.GeneralException The message >> > > > was "Error getting >> > > > http://fedora-prod- >> vm.hull.ac.uk:8080/fedora/get/hull:4994/descMetadat >> > > > a/ >> > > > 20 >> > > > 11-11-28T10:22:40.549Z" . >> > > > at >> > > > >> org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder. >> > > > ja >> > > > va:222) >> > > > at >> > > > >> org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.j >> > > > av >> > > > a:129) >> > > > at >> > > > >> org.apache.axis.encoding.DeserializationContext.endElement(Deserializa >> > > > ti >> > > > onContext.java:1087) >> > > > at >> > > > org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown >> Source) >> > > > at >> > > > >> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown >> > > > Source) >> > > > at >> > > > >> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentD >> > > > is >> > > > patcher.dispatch(Unknown Source) >> > > > at >> > > > >> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unk >> > > > no >> > > > wn Source) >> > > > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown >> > > > Source) >> > > > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown >> > > > Source) >> > > > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) >> > > > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown >> > > > Source) >> > > > at javax.xml.parsers.SAXParser.parse(Unknown Source) >> > > > at >> > > > >> org.apache.axis.encoding.DeserializationContext.parse(DeserializationC >> > > > on >> > > > text.java:227) >> > > > at >> > > org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696) >> > > > at org.apache.axis.Message.getSOAPEnvelope(Message.java:435) >> > > > at >> > > > >> org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderst >> > > > an >> > > > dChecker.java:62) >> > > > at >> > > org.apache.axis.client.AxisClient.invoke(AxisClient.java:206) >> > > > at org.apache.axis.client.Call.invokeEngine(Call.java:2784) >> > > > at org.apache.axis.client.Call.invoke(Call.java:2767) >> > > > at org.apache.axis.client.Call.invoke(Call.java:2443) >> > > > at org.apache.axis.client.Call.invoke(Call.java:2366) >> > > > at org.apache.axis.client.Call.invoke(Call.java:1812) >> > > > at >> > > > >> fedora.server.management.FedoraAPIMBindingSOAPHTTPStub.ingest(FedoraAP >> > > > IM >> > > > BindingSOAPHTTPStub.java:537) >> > > > at >> > > > fedora.client.APIMStubWrapper$1.construct(APIMStubWrapper.java:31) >> > > > at fedora.client.SwingWorker$2.run(SwingWorker.java:131) >> > > > at java.lang.Thread.run(Unknown Source) >> > > > >> > > > >> > > > ___________________________________________________________________ >> > > > >> > > > 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 >> > > > >> > > > >> > > > >> > > > >> > > > -----Original Message----- >> > > > From: aj...@virginia.edu >> [mailto:aj...@virginia.edu](javascript:main.compose() >> > > > Sent: 29 November 2011 8:45 PM >> > > > To: Support and info exchange list for Fedora users. >> > > > Subject: Re: [fcrepo-user] Ingest Question >> > > > >> > > > Richard-- >> > > > >> > > > I'm frankly very dubious that you're being stupid. {grin} >> > > > >> > > > If you don't trace the problem to some kind of network issue, please >> > > > let us have some stacktraces and FOXML. It's far from impossible >> that >> > > > there is some kind of issue here that gets masked by other problems. >> > > > >> > > > If nothing else, perhaps we need to augment the documentation to >> > > > explain more clearly that a "migration"-style FOXML serialization of >> > > > an object has URL-dependencies on the repository from which it was >> > > exported... >> > > > >> > > > --- >> > > > A. Soroka >> > > > Online Library Environment >> > > > the University of Virginia Library >> > > > >> > > > >> > > > >> > > > >> > > > On Nov 29, 2011, at 2:17 PM, Richard Green wrote: >> > > > >> > > >> Rich >> > > >> >> > > >> That's exactly the error we've been seeing. Between the two of us >> I >> > > >> think we have probably stumbled upon a real issue. Either that, or >> > > >> we're both capable of being stupid - certainly not beyond the >> bounds >> > > >> of possibility in my case!!! >> > > >> >> > > >> Richard >> > > >> >> > > >> -----Original Message----- >> > > >> From: Burgis, Richard >> [mailto:burgi...@ais.msu.edu](javascript:main.compose() >> > > >> Sent: 29 November 2011 6:49 PM >> > > >> To: Support and info exchange list for Fedora users. >> > > >> Subject: Re: [fcrepo-user] Ingest Question >> > > >> >> > > >> Thanks. >> > > >> >> > > >> The error is >> > > >> >> org.fcrepo.server.errors.HttpServiceNotFoundException:[DefaultExterna >> > > >> l Co ntentManager] returned an error. The underlying error was a >> > > >> org.fcrepo.server.errors.GeneralException The message was "Error >> > > >> getting >> > > >> http://localhost:8080//fedora/get/uahc:AP00001/source/2011-10- >> 19T18:1 >> > > >> 4 >> > > >> :3 >> > > >> 4.840Z" >> > > >> >> > > >> >> > > >> The Fedora log at this point just contains a Java exception dump >> that >> > > >> > > >> starts out exactly as the above: >> > > >> >> > > >> ERROR 2011-11-29 13:42:36.394 [http-bio-8080-exec-4] >> > > >> (FedoraAPIMBindingSOAPHTTPImpl) Error ingesting >> > > >> org.fcrepo.server.errors.HttpServiceNotFoundException: >> > > >> [DefaultExternalContentManager] returned an error. The underlying >> > > >> error was a org.fcrepo.server.errors.GeneralException The message >> > > >> was >> > > > >> > > >> "Error getting >> > > >> >> > > http://localhost:8080/fedora/get/uahc:AP00001/source/2011-10-19T18:14: >> > > >> 34 >> > > >> .840Z" . >> > > >> at >> > > >> >> org.fcrepo.server.storage.DefaultExternalContentManager.getExternalCo >> > > >> n >> > > >> te >> > > >> nt(DefaultExternalContentManager.java:155) [fcrepo-server- >> 3.5.jar:na] >> > > >> at >> > > >> >> org.fcrepo.server.storage.DefaultDOManager.doCommit(DefaultDOManager. >> > > >> j >> > > >> av >> > > >> a:1203) [fcrepo-server-3.5.jar:na] >> > > >> at >> > > >> >> org.fcrepo.server.storage.SimpleDOWriter.commit(SimpleDOWriter.java:5 >> > > >> 0 >> > > >> 9) >> > > >> [fcrepo-server-3.5.jar:na] >> > > >> at >> > > >> >> > > > >> > > >> org.fcrepo.server.management.DefaultManagement.ingest(DefaultManagement. >> > > >> java:177) [fcrepo-server-3.5.jar:na] >> > > >> at sun.reflect.GeneratedMethodAccessor56.invoke(Unknown >> Source) >> > > > >> > > >> [na:na] >> > > >> at >> > > >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >> > > >> s >> > > >> or >> > > >> Impl.java:25) [na:1.6.0_25] >> > > >> at java.lang.reflect.Method.invoke(Method.java:597) >> > > >> [na:1.6.0_25] >> > > >> at >> > > >> >> org.fcrepo.server.messaging.NotificationInvocationHandler.invoke(Noti >> > > >> f >> > > >> ic >> > > >> ationInvocationHandler.java:68) [fcrepo-server-3.5.jar:na] >> > > >> at $Proxy5.ingest(Unknown Source) [na:na] >> > > >> at >> > > >> >> > > org.fcrepo.server.management.ManagementModule.ingest(ManagementModule. >> > > >> ja >> > > >> va:354) [fcrepo-server-3.5.jar:na] >> > > >> at >> > > >> >> org.fcrepo.server.management.FedoraAPIMBindingSOAPHTTPImpl.ingest(Fed >> > > >> o >> > > >> ra >> > > >> APIMBindingSOAPHTTPImpl.java:83) [fcrepo-server-3.5.jar:na] >> > > >> at >> > > >> >> org.fcrepo.server.management.FedoraAPIMBindingSOAPHTTPSkeleton.ingest >> > > >> ( >> > > >> Fe >> > > >> doraAPIMBindingSOAPHTTPSkeleton.java:355) [fcrepo-common- >> 3.5.jar:na] >> > > >> at sun.reflect.GeneratedMethodAccessor57.invoke(Unknown >> Source) >> > > > >> > > >> [na:na] >> > > >> at >> > > >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces >> > > >> s >> > > >> or >> > > >> Impl.java:25) [na:1.6.0_25] >> > > >> >> > > >> There is a great deal more of course. >> > > >> >> > > >> Rich >> > > >> -----Original Message----- >> > > >> From: aj...@virginia.edu >> [mailto:aj...@virginia.edu](javascript:main.compose() >> > > >> Sent: Tuesday, November 29, 2011 1:30 PM >> > > >> To: Support and info exchange list for Fedora users. >> > > >> Subject: Re: [fcrepo-user] Ingest Question >> > > >> >> > > >> One natural question is why you are wanting to use file:// URLs? Is >> > > >> it >> > > > >> > > >> because you are dealing with very large datastreams (which is often >> > > >> the motivation)? Or for some other reason? As for using http:// >> URLs >> > > >> for external datastreams, it's not difficult to create objects that >> > > >> so >> > > > do. >> > > >> The pattern of URLs to use is essentially arbitrary, as long as >> > > >> Fedora >> > > > >> > > >> can dereference them when appropriate, and the specifics really >> > > >> depend >> > > > >> > > >> on your larger system design criteria. Keep in mind that when using >> > > >> external datastreams, you give up some of Fedora's abilities to >> > > >> manage >> > > > >> > > >> that content, e.g. eventing via JMS or content versioning. >> > > >> >> > > >> As to the specific problem-- it would be helpful if you could >> provide >> > > >> > > >> the section of Fedora's log in which the new repository fails to >> > > >> retrieve the managed datastreams from the old repository. Then we >> > > >> might be able to determine just why that's happening in your >> > > >> situation. If it makes you feel any better about the time you are >> > > >> spending with this problem, I move objects between repositories by >> > > >> this means all the time, so it is possible, and there is some >> > > >> definite >> > > > >> > > >> reason it isn't working for you, and we can find out what that is >> and >> > > > fix it. >> > > >> >> > > >> --- >> > > >> A. Soroka >> > > >> Online Library Environment >> > > >> the University of Virginia Library >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> On Nov 29, 2011, at 1:20 PM, Burgis, Richard wrote: >> > > >> >> > > >>> 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](javascript:main.compose() >> > > >>> 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](javascript:main.compose() >> > > >>>> 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](javascript:main.compose() >> > > >>>>>> 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 >> > > >> >> > > >> >> > > >> ------------------------------------------------------------------- >> -- >> > > >> - >> > > >> -- >> > > >> ------ >> > > >> 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 >> > > > >> > > > >> > > > -------------------------------------------------------------------- >> -- >> > > > -- >> > > > ------ >> > > > 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 >> >> -- >> -- >> Scott Prater >> Library, Instructional, and Research Applications (LIRA) >> Division of Information Technology (DoIT) >> University of Wisconsin - Madison >> pra...@wisc.edu >> >> -------------------------------------------------------------------------- >> ---- >> 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
