Hi, Steve -- I was thinking that FeSL/JAAS could be configured for IP-based authentication, then use the usual XACML policies for authorization. So the IP access would be configured into two places: at the front door (during the authN request), then on the porch (for authZ).
During a little bit of reading now: configuring JAAS for IP-based authentication is apparently not as trivial as it sounds. Most web application containers have their own IP-based access control mechanism; Tomcat uses Valves. Valves and JAAS can be made to play together: essentially, a custom Valve can do an IP check, then set a user principal that then is made available to JAAS: http://java.sys-con.com/node/1876662 There may be a simpler way to do it, but I don't want to hijack this thread more than I already have. -- Scott On 12/02/2011 10:03 AM, Stephen Bayliss 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 > -- 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
