<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: How to split an event at index time? in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353556#M64730</link>
    <description>&lt;P&gt;To recap, the problem is that we have a source whose events need to be split and end up in a certain target format. In this particular case, this is done on a universal forwarder, but the solution applies to a source local to a Splunk indexer too.&lt;/P&gt;

&lt;P&gt;1) In &lt;CODE&gt;inputs.conf&lt;/CODE&gt;, identify the sourcetype as &lt;CODE&gt;intermediate_sourcetype_1&lt;/CODE&gt;.&lt;BR /&gt;
2) In &lt;CODE&gt;props.conf&lt;/CODE&gt; (with &lt;CODE&gt;force_local_processing = true&lt;/CODE&gt;), assign to &lt;CODE&gt;intermediate_sourcetype_1&lt;/CODE&gt; any common &lt;CODE&gt;_raw&lt;/CODE&gt; transformation to a &lt;CODE&gt;SEDCMD&lt;/CODE&gt;, then specify three &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; which we'll call &lt;CODE&gt;transform-clone-1, transform-clone-2, transform-drop&lt;/CODE&gt;.&lt;BR /&gt;
3) In &lt;CODE&gt;transforms.conf&lt;/CODE&gt;, define &lt;CODE&gt;transform-drop&lt;/CODE&gt; as &lt;CODE&gt;REGEX = .*&lt;/CODE&gt;, &lt;CODE&gt;DEST_KEY = queue&lt;/CODE&gt;, &lt;CODE&gt;FORMAT = nullQueue&lt;/CODE&gt;. This transform simply drops the event.&lt;BR /&gt;
4) Still in &lt;CODE&gt;transforms.conf&lt;/CODE&gt;, define &lt;CODE&gt;transform-clone-1&lt;/CODE&gt; as &lt;CODE&gt;REGEX = .*&lt;/CODE&gt;, &lt;CODE&gt;DEST_KEY = _raw&lt;/CODE&gt;, &lt;CODE&gt;FORMAT = $0&lt;/CODE&gt;, &lt;CODE&gt;CLONE_SOURCETYPE = intermediate_sourcetype_2A&lt;/CODE&gt;. &lt;CODE&gt;transform-clone-2&lt;/CODE&gt; is the same except that &lt;CODE&gt;CLONE_SOURCETYPE = intermediate_sourcetype_2B&lt;/CODE&gt;.&lt;BR /&gt;
5) Back in &lt;CODE&gt;props.conf&lt;/CODE&gt;, assign appropriate &lt;CODE&gt;SEDCMD&lt;/CODE&gt; and &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; to &lt;CODE&gt;intermediate_sourcetype_2A&lt;/CODE&gt; and &lt;CODE&gt;intermediate_sourcetype_2B&lt;/CODE&gt;. Make sure to conclude the &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; set with &lt;CODE&gt;transform-switch-sourcetype&lt;/CODE&gt;.&lt;BR /&gt;
6) Finally, back in &lt;CODE&gt;transforms.conf&lt;/CODE&gt;, define &lt;CODE&gt;transform-switch-sourcetype&lt;/CODE&gt; as &lt;CODE&gt;SOURCE_KEY = MetaData:Sourcetype&lt;/CODE&gt;, &lt;CODE&gt;REGEX = .*&lt;/CODE&gt;, &lt;CODE&gt;DEST_KEY = MetaData:Sourcetype&lt;/CODE&gt;, &lt;CODE&gt;FORMAT = sourcetype::target_sourcetype&lt;/CODE&gt;. This transform simply switches the event's sourcetype.&lt;/P&gt;

&lt;P&gt;It's important that &lt;CODE&gt;props.conf&lt;/CODE&gt; not rely on &lt;CODE&gt;source::&lt;/CODE&gt; stanzas to process the events, because that stanza would apply to the cloned events as well as to the original event, resulting in multiple applications of &lt;CODE&gt;SEDCMD&lt;/CODE&gt; and &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt;. That is unlikely to yield the desired results except in really odd circumstances.&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;A note of caution&lt;/STRONG&gt;: keep backups of &lt;CODE&gt;inputs.conf&lt;/CODE&gt;, &lt;CODE&gt;props.conf&lt;/CODE&gt; and &lt;CODE&gt;transforms.conf&lt;/CODE&gt; appearing in the universal forwarder's &lt;CODE&gt;/opt/splunkforwarder/etc/apps/_server_app_&amp;lt;server_class&amp;gt;/local&lt;/CODE&gt; because Splunk Web will wipe them when you change the input configuration—if you edit directly in that folder. The workaround is to build your &lt;CODE&gt;inputs.conf&lt;/CODE&gt;, &lt;CODE&gt;props.conf&lt;/CODE&gt;, and &lt;CODE&gt;transforms.conf&lt;/CODE&gt; in &lt;CODE&gt;/opt/splunk/etc/deployment-apps/_server_app_&amp;lt;server_class&amp;gt;/local&lt;/CODE&gt; on the main Splunk instance. The only caveat I've had with this is that there is seemingly no way to "refresh" the forwarder from Splunk Web (you'd expect that in &lt;CODE&gt;Settings: (Distributed environment) Forwarder management&lt;/CODE&gt;); you must use the command line and issue &lt;CODE&gt;splunk reload deploy-server&lt;/CODE&gt;.&lt;/P&gt;</description>
    <pubDate>Mon, 05 Feb 2018 15:06:43 GMT</pubDate>
    <dc:creator>DUThibault</dc:creator>
    <dc:date>2018-02-05T15:06:43Z</dc:date>
    <item>
      <title>How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353550#M64724</link>
      <description>&lt;P&gt;In a nutshell, I need &lt;CODE&gt;CLONE_SOURCETYPE&lt;/CODE&gt; functionality within a single &lt;CODE&gt;sourcetype&lt;/CODE&gt;. I have events (from a &lt;CODE&gt;[source::]&lt;/CODE&gt; stanza) that come in the form &lt;CODE&gt;&amp;lt;timestamp&amp;gt;,&amp;lt;value1&amp;gt;,&amp;lt;value2&amp;gt;&lt;/CODE&gt; on a Universal Forwarder and I need it to split this into two events &lt;CODE&gt;&amp;lt;timestamp&amp;gt;,&amp;lt;value1&amp;gt;&lt;/CODE&gt; and &lt;CODE&gt;&amp;lt;timestamp&amp;gt;,&amp;lt;value2&amp;gt;&lt;/CODE&gt; which will be both sent to the same &lt;CODE&gt;sourcetype&lt;/CODE&gt;.&lt;/P&gt;

&lt;P&gt;How can this be done?&lt;/P&gt;

&lt;P&gt;I am speculating that I could &lt;CODE&gt;CLONE_SOURCETYPE&lt;/CODE&gt; and have the new &lt;CODE&gt;sourcetype&lt;/CODE&gt; apply a couple of &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; to change the (duplicated) &lt;CODE&gt;_raw&lt;/CODE&gt; and its &lt;CODE&gt;MetaData:Sourcetype&lt;/CODE&gt; (back to the original destination &lt;CODE&gt;sourcetype&lt;/CODE&gt;). Is there a simpler way?&lt;/P&gt;</description>
      <pubDate>Thu, 01 Feb 2018 18:42:58 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353550#M64724</guid>
      <dc:creator>DUThibault</dc:creator>
      <dc:date>2018-02-01T18:42:58Z</dc:date>
    </item>
    <item>
      <title>Re: How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353551#M64725</link>
      <description>&lt;P&gt;do you need them to be the same sourcetype when indexed?  or can you rename the new sourcetype back at search time?  the reason i ask is because the docs make it sound like the cloned event will only get index-time transformations and sed commands.  meaning, it might not go back through the rest of the typing queue?  maybe to prevent looping?  or maybe i'm reading it wrong.&lt;/P&gt;

&lt;P&gt;props.conf&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[clone_test]
TRANSFORMS-clone = clone_sourcetype,trim

[clone_test2]
# rename is done at search time
rename = clone_test
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;transforms.conf&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[trim]
REGEX = ^([^,]+,[^,]+)
FORMAT = $1
DEST_KEY = _raw

[clone_sourcetype]
REGEX = ^([^,]+),[^,]+,(.+)
FORMAT = $1,$2
DEST_KEY = _raw
CLONE_SOURCETYPE = clone_test2
&lt;/CODE&gt;&lt;/PRE&gt;</description>
      <pubDate>Fri, 02 Feb 2018 03:04:27 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353551#M64725</guid>
      <dc:creator>maciep</dc:creator>
      <dc:date>2018-02-02T03:04:27Z</dc:date>
    </item>
    <item>
      <title>Re: How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353552#M64726</link>
      <description>&lt;P&gt;Oh boy. Testing this out yields really unexpected results.&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;props.conf&lt;/STRONG&gt;&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[source::/home/user/testidle]
force_local_processing = true
SEDCMD-a = s/$/ seda/
TRANSFORMS-clone = testidle-clone, testidle-b
sourcetype = whatever

[testidle-cloned]
force_local_processing = true
SEDCMD-b = s/$/ sedb/
TRANSFORMS-switch-sourcetype = testidle-c, switch-sourcetype
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;&lt;STRONG&gt;transforms.conf&lt;/STRONG&gt;&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;[testidle-clone]
CLONE_SOURCETYPE = testidle-cloned
REGEX = .*
DEST_KEY = _raw
FORMAT = $0 testidle-clone

[testidle-b]
REGEX = .*
DEST_KEY = _raw
FORMAT = $0 testidle-b

[testidle-c]
REGEX = .*
DEST_KEY = _raw
FORMAT = $0 testidle-c

[switch-sourcetype]
SOURCE_KEY = MetaData:Sourcetype
REGEX = .*
DEST_KEY = MetaData:Sourcetype
FORMAT = sourcetype::whatever
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;The events that the forwarder sends are then:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;eventdata seda testidle-b
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;and&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;eventdata seda testidle-clone seda sedb testidle-clone testidle-b testidle-c
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;The first event's track is as expected: the &lt;CODE&gt;source::&lt;/CODE&gt; applies a &lt;CODE&gt;SEDCMD&lt;/CODE&gt; and then the transforms &lt;CODE&gt;testidle-clone&lt;/CODE&gt; (which creates the clone) and &lt;CODE&gt;testidle-b&lt;/CODE&gt;. It's the second event which reveals weirdness. It looks like it's not the original raw event that is cloned, but the SEDCMDed one ("eventdata seda") at which point the original sourcetype's &lt;CODE&gt;SEDCMD&lt;/CODE&gt; gets applied &lt;EM&gt;again&lt;/EM&gt; before the new sourcetype's &lt;CODE&gt;SEDCMD&lt;/CODE&gt; gets applied followed by the &lt;EM&gt;original&lt;/EM&gt; sourcetype's &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; (&lt;CODE&gt;clone&lt;/CODE&gt; then &lt;CODE&gt;b&lt;/CODE&gt;) and finally the new sourcetype's &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; (&lt;CODE&gt;c&lt;/CODE&gt; then &lt;CODE&gt;switch-sourcetype&lt;/CODE&gt;). Thankfully, &lt;CODE&gt;switch-sourcetype&lt;/CODE&gt; works as expected (and I checked: if I omit the &lt;CODE&gt;switch-sourcetype&lt;/CODE&gt;, the cloned event comes through with the same payload, albeit under the &lt;CODE&gt;testidle-cloned&lt;/CODE&gt; sourcetype.&lt;/P&gt;

&lt;P&gt;The fact that the event gets cloned twice is, by itself, a bug, methinks.&lt;/P&gt;</description>
      <pubDate>Fri, 02 Feb 2018 19:52:40 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353552#M64726</guid>
      <dc:creator>DUThibault</dc:creator>
      <dc:date>2018-02-02T19:52:40Z</dc:date>
    </item>
    <item>
      <title>Re: How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353553#M64727</link>
      <description>&lt;P&gt;&lt;STRONG&gt;Addendum:&lt;/STRONG&gt; The above behaviour seems due to the &lt;CODE&gt;source::&lt;/CODE&gt; matching (the SPL-99120 bug). Since the cloned event has the same source, it gets matched against &lt;CODE&gt;source::&lt;/CODE&gt; and this is why the &lt;CODE&gt;SEDCMD&lt;/CODE&gt; and cloning occur a second time. If we map the input file directly to a sourcetype, then we get:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;eventdata seda testidle-b
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;and&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;eventdata seda testidle-clone sedb testidle-c
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;which was the original intent.&lt;/P&gt;</description>
      <pubDate>Fri, 02 Feb 2018 20:03:43 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353553#M64727</guid>
      <dc:creator>DUThibault</dc:creator>
      <dc:date>2018-02-02T20:03:43Z</dc:date>
    </item>
    <item>
      <title>Re: How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353554#M64728</link>
      <description>&lt;P&gt;Just out of curiosity, can you explain why you need &lt;CODE&gt;value1&lt;/CODE&gt; and &lt;CODE&gt;value2&lt;/CODE&gt; on separate lines?&lt;/P&gt;</description>
      <pubDate>Sat, 03 Feb 2018 02:48:13 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353554#M64728</guid>
      <dc:creator>micahkemp</dc:creator>
      <dc:date>2018-02-03T02:48:13Z</dc:date>
    </item>
    <item>
      <title>Re: How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353555#M64729</link>
      <description>&lt;P&gt;@micahkemp It's a conversion thing. &lt;CODE&gt;collectd&lt;/CODE&gt; in &lt;CODE&gt;csv&lt;/CODE&gt; mode produces e.g. &lt;CODE&gt;load&lt;/CODE&gt; events consisting of &lt;CODE&gt;&amp;lt;timestamp&amp;gt;,&amp;lt;shortterm&amp;gt;,&amp;lt;midterm&amp;gt;,&amp;lt;longterm&amp;gt;&lt;/CODE&gt;, but in &lt;CODE&gt;graphite&lt;/CODE&gt; mode it produces three separate events ( &lt;CODE&gt;&amp;lt;host.plugin.metric&amp;gt; &amp;lt;shortterm&amp;gt; &amp;lt;timestamp&amp;gt;&lt;/CODE&gt;, &lt;CODE&gt;&amp;lt;host.plugin.metric&amp;gt; &amp;lt;midterm&amp;gt; &amp;lt;timestamp&amp;gt;&lt;/CODE&gt;, &lt;CODE&gt;&amp;lt;host.plugin.metric&amp;gt; &amp;lt;longterm&amp;gt; &amp;lt;timestamp&amp;gt;&lt;/CODE&gt;). I'm converting the former into the latter so that what the universal forwarder sends to the indexer is in the latter format (and bears the latter sourcetype).&lt;/P&gt;

&lt;P&gt;I would obviously not need to do this splitting/conversion if I could use a &lt;CODE&gt;linux:collectd:csv&lt;/CODE&gt; sourcetype of my own, but the intent here is to be able to feed the &lt;CODE&gt;Splunk_TA_linux&lt;/CODE&gt; (3412) application transparently.&lt;/P&gt;</description>
      <pubDate>Mon, 05 Feb 2018 14:23:40 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353555#M64729</guid>
      <dc:creator>DUThibault</dc:creator>
      <dc:date>2018-02-05T14:23:40Z</dc:date>
    </item>
    <item>
      <title>Re: How to split an event at index time?</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353556#M64730</link>
      <description>&lt;P&gt;To recap, the problem is that we have a source whose events need to be split and end up in a certain target format. In this particular case, this is done on a universal forwarder, but the solution applies to a source local to a Splunk indexer too.&lt;/P&gt;

&lt;P&gt;1) In &lt;CODE&gt;inputs.conf&lt;/CODE&gt;, identify the sourcetype as &lt;CODE&gt;intermediate_sourcetype_1&lt;/CODE&gt;.&lt;BR /&gt;
2) In &lt;CODE&gt;props.conf&lt;/CODE&gt; (with &lt;CODE&gt;force_local_processing = true&lt;/CODE&gt;), assign to &lt;CODE&gt;intermediate_sourcetype_1&lt;/CODE&gt; any common &lt;CODE&gt;_raw&lt;/CODE&gt; transformation to a &lt;CODE&gt;SEDCMD&lt;/CODE&gt;, then specify three &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; which we'll call &lt;CODE&gt;transform-clone-1, transform-clone-2, transform-drop&lt;/CODE&gt;.&lt;BR /&gt;
3) In &lt;CODE&gt;transforms.conf&lt;/CODE&gt;, define &lt;CODE&gt;transform-drop&lt;/CODE&gt; as &lt;CODE&gt;REGEX = .*&lt;/CODE&gt;, &lt;CODE&gt;DEST_KEY = queue&lt;/CODE&gt;, &lt;CODE&gt;FORMAT = nullQueue&lt;/CODE&gt;. This transform simply drops the event.&lt;BR /&gt;
4) Still in &lt;CODE&gt;transforms.conf&lt;/CODE&gt;, define &lt;CODE&gt;transform-clone-1&lt;/CODE&gt; as &lt;CODE&gt;REGEX = .*&lt;/CODE&gt;, &lt;CODE&gt;DEST_KEY = _raw&lt;/CODE&gt;, &lt;CODE&gt;FORMAT = $0&lt;/CODE&gt;, &lt;CODE&gt;CLONE_SOURCETYPE = intermediate_sourcetype_2A&lt;/CODE&gt;. &lt;CODE&gt;transform-clone-2&lt;/CODE&gt; is the same except that &lt;CODE&gt;CLONE_SOURCETYPE = intermediate_sourcetype_2B&lt;/CODE&gt;.&lt;BR /&gt;
5) Back in &lt;CODE&gt;props.conf&lt;/CODE&gt;, assign appropriate &lt;CODE&gt;SEDCMD&lt;/CODE&gt; and &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; to &lt;CODE&gt;intermediate_sourcetype_2A&lt;/CODE&gt; and &lt;CODE&gt;intermediate_sourcetype_2B&lt;/CODE&gt;. Make sure to conclude the &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt; set with &lt;CODE&gt;transform-switch-sourcetype&lt;/CODE&gt;.&lt;BR /&gt;
6) Finally, back in &lt;CODE&gt;transforms.conf&lt;/CODE&gt;, define &lt;CODE&gt;transform-switch-sourcetype&lt;/CODE&gt; as &lt;CODE&gt;SOURCE_KEY = MetaData:Sourcetype&lt;/CODE&gt;, &lt;CODE&gt;REGEX = .*&lt;/CODE&gt;, &lt;CODE&gt;DEST_KEY = MetaData:Sourcetype&lt;/CODE&gt;, &lt;CODE&gt;FORMAT = sourcetype::target_sourcetype&lt;/CODE&gt;. This transform simply switches the event's sourcetype.&lt;/P&gt;

&lt;P&gt;It's important that &lt;CODE&gt;props.conf&lt;/CODE&gt; not rely on &lt;CODE&gt;source::&lt;/CODE&gt; stanzas to process the events, because that stanza would apply to the cloned events as well as to the original event, resulting in multiple applications of &lt;CODE&gt;SEDCMD&lt;/CODE&gt; and &lt;CODE&gt;TRANSFORMS&lt;/CODE&gt;. That is unlikely to yield the desired results except in really odd circumstances.&lt;/P&gt;

&lt;P&gt;&lt;STRONG&gt;A note of caution&lt;/STRONG&gt;: keep backups of &lt;CODE&gt;inputs.conf&lt;/CODE&gt;, &lt;CODE&gt;props.conf&lt;/CODE&gt; and &lt;CODE&gt;transforms.conf&lt;/CODE&gt; appearing in the universal forwarder's &lt;CODE&gt;/opt/splunkforwarder/etc/apps/_server_app_&amp;lt;server_class&amp;gt;/local&lt;/CODE&gt; because Splunk Web will wipe them when you change the input configuration—if you edit directly in that folder. The workaround is to build your &lt;CODE&gt;inputs.conf&lt;/CODE&gt;, &lt;CODE&gt;props.conf&lt;/CODE&gt;, and &lt;CODE&gt;transforms.conf&lt;/CODE&gt; in &lt;CODE&gt;/opt/splunk/etc/deployment-apps/_server_app_&amp;lt;server_class&amp;gt;/local&lt;/CODE&gt; on the main Splunk instance. The only caveat I've had with this is that there is seemingly no way to "refresh" the forwarder from Splunk Web (you'd expect that in &lt;CODE&gt;Settings: (Distributed environment) Forwarder management&lt;/CODE&gt;); you must use the command line and issue &lt;CODE&gt;splunk reload deploy-server&lt;/CODE&gt;.&lt;/P&gt;</description>
      <pubDate>Mon, 05 Feb 2018 15:06:43 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/How-to-split-an-event-at-index-time/m-p/353556#M64730</guid>
      <dc:creator>DUThibault</dc:creator>
      <dc:date>2018-02-05T15:06:43Z</dc:date>
    </item>
  </channel>
</rss>

