Not at all. I have yet to come across a real-world deployment of Fedora that
didn't involve at least a little bit of network-layer... um... "fun". {grin}
If you get that network-layer "fun" resolved and there are other problems,
we'll be here.
The question of using "file://" URLs for external datastreams is a little
different, and I'd still be interested to hear what you're trying to do in that
way, particularly as a means of discovering where Fedora may need to grow and
expand functionality.
---
A. Soroka
Online Library Environment
the University of Virginia Library
On Nov 29, 2011, at 3:36 PM, Burgis, Richard wrote:
> I'm sorry I'm slow. Of course you're right. The ssh'ing into the server
> machine and trying to wget. My connection times out each time. Just to
> be sure I tried the same thing for the target server and it worked like
> a charm.
>
> We have a firewall problem. (Or at least a firewall problem.)
>
> On the off chance it's not here is a non-importing file. But for what
> it's worth. When I had localhost in the locations, it failed quickly.
> With this one it fails slowly, which is what you'd expect from Fedora
> retrying the connection several times before giving up.
>
> Thank you
> Rich
>
> -----Original Message-----
> From: aj...@virginia.edu [mailto:aj...@virginia.edu]
> Sent: Tuesday, November 29, 2011 3:06 PM
> To: Support and info exchange list for Fedora users.
> Subject: Re: [fcrepo-user] Ingest Question
>
> I hate to bang on the same drum, but I'm still not yet absolutely clear
> about one thing: when you say that "I just tried ingesting from the
> source repository" (I assume you mean via the Java admin tool, or
> perhaps with the command-line utilities) and "I tried connecting via the
> web and successfully retrieved my file." do you mean exactly that you
> tried _from the new repository machine_ or that perhaps you tried from
> your desktop or some other machine? I just want to be very, very sure
> that the new repository machine can successfully connect via HTTP to the
> old repository machine, without worrying about Fedora's vagaries in
> making that connection. Essentially, I'm trying to separate any problems
> with firewalls or network-layer access restrictions or the like from
> problems with Fedora (in which I'm actually quite willing to believe
> {grin}).
>
> That aside, I think it may be useful to dig into the old repository. Can
> you give us the output of a failing-to-ingest "Migration"-style export
> in its totality?
>
> ---
> A. Soroka
> Online Library Environment
> the University of Virginia Library
>
>
>
>
> On Nov 29, 2011, at 2:42 PM, Burgis, Richard wrote:
>
>> I really liked that answer. It made sense. I changed the configuration
>> file, restarted the server and did the export. The contentLocation was
>> changed from localhost to the correct IP address. I tried to ingest
> the
>> object, which labored a long time and ended up with the same error.
> But
>> this time the error referenced the IP address. I just tried ingesting
>> from the source repository and got the same error.
>>
>> The log on the source repository says that the object was requested
> and
>> exported successfully.
>>
>> What was Huxley's line: "A beautiful theory wrecked by an inconvenient
>> fact" (or words to that effect)
>>
>> Thanks
>> Rich
>>
>> -----Original Message-----
>> From: aj...@virginia.edu [mailto:aj...@virginia.edu]
>> Sent: Tuesday, November 29, 2011 2:26 PM
>> To: Support and info exchange list for Fedora users.
>> Subject: Re: [fcrepo-user] Ingest Question
>>
>> I agree that it seems a little strange. {grin}
>>
>> If the logs of the new repository show it requesting
>> "http://localhost:8080..."; it is going to be requesting that URL of
>> itself, and it certainly won't get it! It seems that the export from
> the
>> old repository has URLs that are containing "http://localhost:8080...";
>> and not an actual externally discoverable address of the machine. I'm
>> not very familiar with the export codebase, so I welcome advice from
> the
>> committers who are, but I believe this may be the root of your
> problem.
>>
>> If, as I believe is the case, the construction of that URL is governed
>> by the parameter in fedora.fcfg:
>>
>> <param name="fedoraServerHost" value="my.host.name.was.here">
>> <comment>Defines the host name for the Fedora server, as seen from
>> the
>> outside world.</comment>
>> </param>
>>
>> then you might try changing that value from "localhost" to something
> the
>> new machine can find (even a bare IP address), restarting the old
>> repository, and redoing a single export to see if the URLs for managed
>> datastreams change. If they do (and I'm pretty confident that they
> will)
>> you can try importing that object to see if all goes well.
>>
>> ---
>> A. Soroka
>> Online Library Environment
>> the University of Virginia Library
>>
>>
>>
>>
>> On Nov 29, 2011, at 2:18 PM, Burgis, Richard wrote:
>>
>>> Actually the first server is on a second windows machine in my
> office,
>>> and the second is running on Linux somewhere in our data center. I
>> tried
>>> connecting via the web and successfully retrieved my file. However,
>>> since the server is on a different machine I had to change the
>> localhost
>>> to the IP address of that machine.
>>>
>>> This seems suspicious to me. I set the first machine up with all
>>> defaults, thus the host defaulted to localhost. I'm wondering if I
>>> should reinstall using the address of the machine instead.
>>>
>>> I checked the source server and there is nothing in the log other
> than
>> I
>>> gave you the object you asked for.
>>>
>>> Thanks
>>> Rich
>>>
>>> -----Original Message-----
>>> From: aj...@virginia.edu [mailto:aj...@virginia.edu]
>>> Sent: Tuesday, November 29, 2011 2:08 PM
>>> To: Support and info exchange list for Fedora users.
>>> Subject: Re: [fcrepo-user] Ingest Question
>>>
>>> That's pretty much what we'd expect. I assume you have the new
>>> repository running on some other port on the same machine? Now,
>> assuming
>>> that you can retrieve that exact URL for the managed datastream
>>>
>>
> (http://localhost:8080//fedora/get/uahc:AP00001/source/2011-10-19T18:14:
>>> 34.840Z) via 'wget' or the like from the new repository machine, I
>> would
>>> ask you to show us what the log for the _old_ repository says at that
>>> moment. Is the request being received and if so, why isn't it being
>>> served? Presumably you should either see no request being received
> (in
>>> which case we have a problem around the repository) or some kind of
>>> exception is being thrown to indicate why that datastream won't be
>>> served.
>>>
>>> ---
>>> A. Soroka
>>> Online Library Environment
>>> the University of Virginia Library
>>>
>>>
>>>
>>>
>>> On Nov 29, 2011, at 1:49 PM, Burgis, Richard wrote:
>>>
>>>> Thanks.
>>>>
>>>> The error is
>>>>
>>>
>>
> org.fcrepo.server.errors.HttpServiceNotFoundException:[DefaultExternalCo
>>>> 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:14: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.getExternalConte
>>>> nt(DefaultExternalContentManager.java:155)
> [fcrepo-server-3.5.jar:na]
>>>> at
>>>>
>>>
>>
> org.fcrepo.server.storage.DefaultDOManager.doCommit(DefaultDOManager.jav
>>>> a:1203) [fcrepo-server-3.5.jar:na]
>>>> at
>>>>
>>>
>>
> org.fcrepo.server.storage.SimpleDOWriter.commit(SimpleDOWriter.java:509)
>>>> [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(DelegatingMethodAccessor
>>>> 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(Notific
>>>> 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(Fedora
>>>> 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(DelegatingMethodAccessor
>>>> 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]
>>>> 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]
>>>>> Sent: Tuesday, November 29, 2011 12:57 PM
>>>>> To: Support and info exchange list for Fedora users.
>>>>> Subject: Re: [fcrepo-user] Ingest Question
>>>>>
>>>>> If I understand you rightly you are using the "Migrate" style of
>>>> export,
>>>>> so that managed datastreams will be expressed in the exported FOXML
>>> as
>>>>> URLs back into the original repository. If, by any chance, the
>>>> original
>>>>> repository URLs are inaccessible at the time of ingest (e.g.,
>> because
>>>> of
>>>>> XACML policy), you may see some funny behavior. It's something that
>>>> has
>>>>> bitten me before because of my own absent-mindedness and you might
>>>> want
>>>>> to check to make sure it's not happening to you. It's easy to check
>>> by
>>>>> taking one of those URLs and retrieving it _from the machine on
>> which
>>>>> the new repository is running_ right before you start the ingest,
>>>> using
>>>>> a tool like 'wget' or 'curl'. If this fails, it should at least
> give
>>>> you
>>>>> more information about why it's happening (whether you have an
> XACML
>>>>> policy problem or, like me, are a bit absentminded and prone to
>>>> turning
>>>>> things off without remembering you did {grin}).
>>>>>
>>>>> ---
>>>>> A. Soroka
>>>>> Online Library Environment
>>>>> the University of Virginia Library
>>>>>
>>>>>
>>>>>
>>>>>> They are both using Akubra module. From the logs it appears that
>> the
>>>>> object was not in low level storage.
>>>>>>
>>>>>> I did try using the export file directly as ingest. That seemed
> the
>>>>> most straight forward way to do this. However it refers to
> locations
>>>> in
>>>>> the source repository for the managed datastreams and the ingest
>>> could
>>>>> not find them. That's why I tried changing to a file URL.
>>>>>>
>>>>>> I have not changed the policy file to allow this. Thank you very
>>> much
>>>>> this sounds promising.
>>>>>>
>>>>>> My other question relates to why I cannot ingest objects with
>>> managed
>>>>> datastreams directly from the original repository.
>>>>>>
>>>>>> My biggest problem is that Fedora comes with a huge set of
> concepts
>>>> to
>>>>> digest all at once in support of it capabilities. Getting by that
>>> will
>>>>> be the challenge.
>>>>>>
>>>>>> Thank you
>>>>>> Rich
>>>>>> -----Original Message-----
>>>>>> From: Benjamin Armintor [mailto:armin...@gmail.com]
>>>>>> Sent: Tuesday, November 29, 2011 12:25 PM
>>>>>> To: Support and info exchange list for Fedora users.
>>>>>> Subject: Re: [fcrepo-user] Ingest Question
>>>>>>
>>>>>> Also, just in case:
>>>>>> https://wiki.duraspace.org/display/FEDORA35/Using+File+URIs
>>>>>>
>>>>>> On Tue, Nov 29, 2011 at 12:19 PM, Benjamin Armintor
>>>>> <armin...@gmail.com> wrote:
>>>>>>> Richard (the first):
>>>>>>> Can you provide a bit more detail about the configuration of the
>>> two
>>>>>>> fedoras (are they both using the same storage module?), what
>>> exactly
>>>>>>> it is you're trying to (it sounds like you're trying to submit
> the
>>>>>>> exported foxml as the body of an ingest request), and the type of
>>>> 500
>>>>>>> errors you're getting (or any information from the logs)?
>>>>>>>
>>>>>>> If you're changing the contentLocations to be file uris, did you
>>>> also
>>>>>>> update the relevant policy to allow resolution of those uris?
>>>>>>>
>>>>>>> - Ben
>>>>>>>
>>>>>>> On Tue, Nov 29, 2011 at 12:00 PM, Richard Green
>>> <r.gr...@hull.ac.uk>
>>>>> wrote:
>>>>>>>> Rich
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Don't assume that it's just you. This sounds rather familiar
> and
>>>>> we've been
>>>>>>>> wondering if it was *us*. Are you trying this with the Fedora
>>> Java
>>>>> admin
>>>>>>>> client (ingest object(s) from repository)? If so - exactly what
>>>>> error
>>>>>>>> message do you get? What version of Fedora are you using?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard
>>>>>>>>
>>>>>>>>
>>> ___________________________________________________________________
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Richard Green
>>>>>>>>
>>>>>>>> Consultant to Library & Learning Innovation, University of Hull
>>>>>>>>
>>>>>>>> managing the History DMP and Hydra (Hull) Projects
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://hydra.hull.ac.uk
>>>>>>>>
>>>>>>>> http://hydrangeainhull.wordpress.com
>>>>>>>>
>>>>>>>> http://projecthydra.org
>>>>>>>>
>>>>>>>> http://historydmp.wordpress.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> From: Burgis, Richard [mailto:burgi...@ais.msu.edu]
>>>>>>>> Sent: 29 November 2011 4:04 PM
>>>>>>>> To: Support and info exchange list for Fedora users.
>>>>>>>> Subject: [fcrepo-user] Ingest Question
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm moving a test repository and trying various methods to get
> it
>>>> to
>>>>> work.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> For objects with embedded content (X), I have no problem
>>> ingesting
>>>>> from the
>>>>>>>> source repository. But when I try ingesting objects with Managed
>>>>> content
>>>>>>>> (M), I get errors saying that the managed content cannot be
>> found.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I tried exporting the objects and ingesting the exported
> objects,
>>>>> but I get
>>>>>>>> the same result.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I modified the contentLocation to use file URLs pointing to the
>>>>> location of
>>>>>>>> the content in the file system. This time the ingest succeeded,
>>> but
>>>>> I got
>>>>>>>> errors (500?) when I tried to edit or view the content. I got
> the
>>>>> same error
>>>>>>>> when I attempted to re-import it via the Admin program. I was
>>>>> finally able
>>>>>>>> to get the import to work after purging the items.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> This seems unreasonable as a process, so I would assume that I
> am
>>>>> missing
>>>>>>>> something critical.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Any suggestions?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Rich
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>
>>
> ------------------------------------------------------------------------
>>>>> ------
>>>>>>>> All the data continuously generated in your IT infrastructure
>>>>>>>> contains a definitive record of customers, application
>>> performance,
>>>>>>>> security threats, fraudulent activity, and more. Splunk takes
>> this
>>>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>>>>> _______________________________________________
>>>>>>>> Fedora-commons-users mailing list
>>>>>>>> Fedora-commons-users@lists.sourceforge.net
>>>>>>>>
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> ------------------------------------------------------------------------
>>>>> ------
>>>>>> All the data continuously generated in your IT infrastructure
>>>>>> contains a definitive record of customers, application
> performance,
>>
>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>
>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>>> _______________________________________________
>>>>>> Fedora-commons-users mailing list
>>>>>> Fedora-commons-users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> ------------------------------------------------------------------------
>>>>> ------
>>>>>> All the data continuously generated in your IT infrastructure
>>>>>> contains a definitive record of customers, application
> performance,
>>
>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>
>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>>> _______________________________________________
>>>>>> Fedora-commons-users mailing list
>>>>>> Fedora-commons-users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> ------------------------------------------------------------------------
>>>>> ------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>> _______________________________________________
>>>>> Fedora-commons-users mailing list
>>>>> Fedora-commons-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>>>
>>>>>
>>>>
>>>
>>
> ------------------------------------------------------------------------
>>>> ------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>> _______________________________________________
>>>>> Fedora-commons-users mailing list
>>>>> Fedora-commons-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
>>>>
>>>>
>>>>
>>>
>>
> ------------------------------------------------------------------------
>>>> ------
>>>> 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
> <uahc_SpartanArchives.xml>------------------------------------------------------------------------------
> 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
