This seems to work well in dev http://httpd.apache.org/docs/2.2/mod/mod_deflate.html#input Please add the following to the crash-reporter config (/etc/httpd/conf.d/crash-reports.mozilla.com.conf for collectors, via puppet): <Location /submit> LimitRequestBody 20971520 SetInputFilter DEFLATE </Location>

If it is possible to make this today that would be grand, I was out sick so I filed this later than I had hoped to

:rhelmer - i have committed this directive to socorro-stage (crash-reports) per your request. it should be available within 30 minutes. % svn diff Index: modules/webapp/files/socorro-stage/collector/etc-httpd/domains/crash-reports.mozilla.com.conf =================================================================== --- modules/webapp/files/socorro-stage/collector/etc-httpd/domains/crash-reports.mozilla.com.conf (revision 54093) +++ modules/webapp/files/socorro-stage/collector/etc-httpd/domains/crash-reports.mozilla.com.conf (working copy) @@ -11,6 +11,7 @@ <Location /submit> LimitRequestBody 20971520 + SetInputFilter DEFLATE </Location> ReWriteEngine on

This does not appear to have been deployed: [rhelmer@socorro-collector2.stage.webapp.phx1 ~]$ grep DEFLATE /etc/httpd/conf.d/crash-reports.mozilla.com.conf [rhelmer@socorro-collector2.stage.webapp.phx1 ~]$

(In reply to Robert Helmer [:rhelmer] from comment #3) > This does not appear to have been deployed: > > [rhelmer@socorro-collector2.stage.webapp.phx1 ~]$ grep DEFLATE > /etc/httpd/conf.d/crash-reports.mozilla.com.conf > [rhelmer@socorro-collector2.stage.webapp.phx1 ~]$ Same story on socorro-collector1 fwiw.

That's the wrong file. See /etc/httpd/mozilla/domains/crash-reports.mozilla.com.conf. [root@socorro-collector2.stage.webapp.phx1 httpd]# pwd /etc/httpd -rw-r--r-- 1 root root 1172 Nov 16 2011 conf.d/crash-reports.mozilla.com.conf -rw-r--r-- 1 root root 1245 Dec 7 15:23 mozilla/domains/crash-reports.mozilla.com.conf # diff conf.d/crash-reports.mozilla.com.conf mozilla/domains/crash-reports.mozilla.com.conf 4a5 > ServerAlias crash-reports-phx.allizom.org 12a14 > SetInputFilter DEFLATE mozilla/domains the the current layout scheme for domains... it's what puppet is managing (although in some legacy way it might be managing the conf.d copy as well... don't know for sure). Just for confirmation: [root@socorro-collector2.stage.webapp.phx1 httpd]# grep mozilla conf/* conf.d/* conf.d/mozilla.conf:include mozilla/*.conf conf.d/mozilla.conf:include mozilla/domains/*.conf ... so mozilla and mozilla/domains are definitely part of the config... no concerns there. cturra, let's remove the copies in conf.d. I don't see any obvious reason why they should exist, and I presume they pre-date puppetization. rhelmer, if you can find any other nodes that are like this, let us know.

:jakem - thnx for the detailed updated. i just had a look at /etc/httpd/conf.d/ to see what files were managed by puppet and the crash-reports apache config wasn't... [root@socorro-collector1.stage.webapp.phx1 ~]# puppet-ls /etc/httpd/conf.d/ /etc/httpd/conf.d/hostname.conf /etc/httpd/conf.d/mozilla.conf i have since manually removed these files and restarted the apache process. [root@socorro-collector1.stage.webapp.phx1 conf.d]# mv crash-reports.mozilla.com.conf /home/cturra/ [root@socorro-collector1.stage.webapp.phx1 conf.d]# apachectl graceful :rhelmer - can you please confirm everything is functioning as expected still?

Note for the future: it has recently been shown to me that "puppet-ls" is *not* trustworthy at all anymore. Those files could be under puppet control even though they're not shown. I'm not saying that they *are*, only that we can't be sure based on puppet-ls. :) Bug 816571 is another example of this... files under puppet control not shown by puppet-ls. I'm pretty sure I've seen the opposite at times too... files puppet-ls thinks are managed by puppet, but actually are not anymore (they were at one time, but no longer).

:jakem - tis true. but in this case, it looks like we're in the clear... [root@socorro-collector2.stage.webapp.phx1 conf.d]# ls crash-reports.mozilla.com.conf ls: cannot access crash-reports.mozilla.com.conf: No such file or directory [root@socorro-collector2.stage.webapp.phx1 conf.d]# puppet agent -t --noop info: Retrieving plugin info: Loading facts in /var/lib/puppet/lib/facter/customFacts.rb info: Loading facts in /var/lib/puppet/lib/facter/available_package_updates.rb info: Loading facts in /var/lib/puppet/lib/facter/vmware_version.rb info: Loading facts in /var/lib/puppet/lib/facter/archlib.rb info: Loading facts in /var/lib/puppet/lib/facter/rhnproxy.rb info: Loading facts in /var/lib/puppet/lib/facter/concat_basedir.rb info: Loading facts in /var/lib/puppet/lib/facter/ossecserver.rb info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb info: Loading facts in /var/lib/puppet/lib/facter/mysql_version.rb info: Loading facts in /var/lib/puppet/lib/facter/ip6tables_version.rb info: Loading facts in /var/lib/puppet/lib/facter/default_gateway.rb info: Loading facts in /var/lib/puppet/lib/facter/puppetmaster.rb info: Loading facts in /var/lib/puppet/lib/facter/pe_version.rb info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb info: Loading facts in /var/lib/puppet/lib/facter/partitions.rb info: Loading facts in /var/lib/puppet/lib/facter/iptables_version.rb info: Loading facts in /var/lib/puppet/lib/facter/mysql_databases.rb info: Loading facts in /var/lib/puppet/lib/facter/ldapvip.rb info: Loading facts in /var/lib/puppet/lib/facter/hp_array_utils.rb info: Loading facts in /var/lib/puppet/lib/facter/raidcontroller.rb info: Loading facts in /var/lib/puppet/lib/facter/lldp.rb info: Loading facts in /var/lib/puppet/lib/facter/pythonversion.rb info: Loading facts in /var/lib/puppet/lib/facter/datacenter.rb info: Caching catalog for socorro-collector2.stage.webapp.phx1.mozilla.com info: Applying configuration version '54195' notice: Finished catalog run in 141.21 seconds

(In reply to Chris Turra [:cturra] from comment #6) > :rhelmer - can you please confirm everything is functioning as expected > still? It appears to be working now, yes. I submitted a gzipped crash report to the URL https://crash-reports.allizom.org/submit?id={aa3c5121-dab2-40e2-81ca-7ea25febc110}&version=20.0a1&buildid=20121210151333 which seems to have submitted successfully and gave me the crash report ID bp-4b208d8e-94fd-4875-b7af-17e482121211.