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
