<?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: Splunk fails to monitor zip file in Getting Data In</title>
    <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20973#M3092</link>
    <description>&lt;P&gt;With Foundstone or some other application?&lt;/P&gt;</description>
    <pubDate>Thu, 15 Dec 2011 16:09:41 GMT</pubDate>
    <dc:creator>sdwilkerson</dc:creator>
    <dc:date>2011-12-15T16:09:41Z</dc:date>
    <item>
      <title>Splunk fails to monitor zip file</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20970#M3089</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;

&lt;P&gt;Trying to have Splunk monitor standard scan-reports from Foundstone (Vulnerability Assessment Scanner), but repeatedly seeing this in the splunkd.log: &lt;/P&gt;

&lt;P&gt;&lt;EM&gt;11-22-2011 17:13:26.759 -0500 ERROR ArchiveFile - In archive '/data/splunk/splunk-4.2.4/var/spool/splunk/Monthly-Full-2010-102811.csv.zip': Bad ZIP file&lt;/EM&gt;&lt;/P&gt;

&lt;P&gt;This zip file opens fine on the windows system with the built-in zip, and on linux with "unzip."&lt;/P&gt;

&lt;UL&gt;
&lt;LI&gt;Any ideas what is causing the problem?&lt;/LI&gt;
&lt;LI&gt;Is it possible that Foundstone uses a compression algorithm that Splunk doesn't understand and if so, how can we test for this?&lt;/LI&gt;
&lt;LI&gt;Any idea on how to get around it besides a scripted input?&lt;/LI&gt;
&lt;/UL&gt;

&lt;P&gt;Thanks,&lt;BR /&gt;
Sean&lt;/P&gt;</description>
      <pubDate>Tue, 22 Nov 2011 22:29:56 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20970#M3089</guid>
      <dc:creator>sdwilkerson</dc:creator>
      <dc:date>2011-11-22T22:29:56Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk fails to monitor zip file</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20971#M3090</link>
      <description>&lt;P&gt;I am haveing the same issue.  Did you ever find a salution?&lt;/P&gt;</description>
      <pubDate>Thu, 15 Dec 2011 15:53:19 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20971#M3090</guid>
      <dc:creator>hartfoml</dc:creator>
      <dc:date>2011-12-15T15:53:19Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk fails to monitor zip file</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20972#M3091</link>
      <description>&lt;P&gt;Answering my own question.&lt;/P&gt;

&lt;P&gt;The problem we found with Foundstone, is that it saves the CSV report in a hierarchical directory structure with windows style backslash characters to note new directories.  This is normally ok, but I believe that the Foundstone zipping function inserts the first directory in some strange way where Linux/python interpret it as a regular backslash character and not a directory.&lt;/P&gt;

&lt;P&gt;You can see with the linux unzip command the file is not corrupt, but the resulting contents look funny:&lt;/P&gt;

&lt;PRE&gt;&lt;CODE&gt;sean@ubuntu:/tmp/temp$ unzip -lvt Monthly-Full-2010-102811.csv.zip 
Archive:  Monthly-Full-2010-102811.csv.zip
    testing: 18\CSV/en/authenticated_hosts.csv   OK
    testing: 18\CSV/en/csvmanifest.xml   OK
    testing: 18\CSV/en/network_assets.csv   OK
    testing: 18\CSV/en/vulnerabilities.csv   OK
No errors detected in compressed data of Monthly-Full-2010-102811.csv.zip.
&lt;/CODE&gt;&lt;/PRE&gt;

&lt;P&gt;I believe that Splunk's monitoring process is doing some input validation and getting stuck on this backslash character.&lt;/P&gt;

&lt;P&gt;The way I found to get around this issue, is to write a small wrapper to unzip the file in advance then have Splunk eat the files inside.&lt;/P&gt;

&lt;P&gt;I found no output options in the Foundstone management UI that could control this behavior.&lt;/P&gt;

&lt;P&gt;Best,&lt;/P&gt;

&lt;P&gt;Sean&lt;/P&gt;</description>
      <pubDate>Thu, 15 Dec 2011 16:09:19 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20972#M3091</guid>
      <dc:creator>sdwilkerson</dc:creator>
      <dc:date>2011-12-15T16:09:19Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk fails to monitor zip file</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20973#M3092</link>
      <description>&lt;P&gt;With Foundstone or some other application?&lt;/P&gt;</description>
      <pubDate>Thu, 15 Dec 2011 16:09:41 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20973#M3092</guid>
      <dc:creator>sdwilkerson</dc:creator>
      <dc:date>2011-12-15T16:09:41Z</dc:date>
    </item>
    <item>
      <title>Re: Splunk fails to monitor zip file</title>
      <link>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20974#M3093</link>
      <description>&lt;P&gt;Great this is exactly what I needed.  If it's not too much trouble can you post the unzip code you used.  Thanks ever so much.  I am using Founstone too and want to get the scan data directly without the operator having to uncompress the reports.&lt;/P&gt;</description>
      <pubDate>Thu, 15 Dec 2011 16:15:40 GMT</pubDate>
      <guid>https://community.splunk.com/t5/Getting-Data-In/Splunk-fails-to-monitor-zip-file/m-p/20974#M3093</guid>
      <dc:creator>hartfoml</dc:creator>
      <dc:date>2011-12-15T16:15:40Z</dc:date>
    </item>
  </channel>
</rss>

