There is an svn tag ready to be pulled at http://socorro.googlecode.com/svn/tags/production/a5v1/dist/ which can be pulled by the command "svn checkout http://socorro.googlecode.com/svn/tags/production/a5v1/dist/" You'll need modpython-collector/, processor/, and pylons/. There is a README file located within each directory with deployment instructions.
Assignee: server-ops → aravind
Component: Server Operations: Web Content Push → Server Operations
OS: Linux → All
Hardware: PC → All
Additional configuration: 1) please set saveProcessedMinidumps = True in config.py (for the processor). 2) in case it wasn't clear, we're going to start with a clean database 3) the database should have the partitioning set up via functions.sql and partitions.sql After setup, please run the following SQL (we will have an admin function for this in future versions): INSERT INTO branches (product, version, branch) VALUES ('Firefox', '3.0a4', '1.9'); INSERT INTO branches (product, version, branch) VALUES ('Firefox', '3.0a5pre', '1.9'); INSERT INTO branches (product, version, branch) VALUES ('Firefox', '3.0a5', '1.9');
so is the stuff in bug 378237 invalid now? Should I replace the collector code with the stuff in modpython-collector?
(In reply to comment #2) > so is the stuff in bug 378237 invalid now? Should I replace the collector code > with the stuff in modpython-collector? > I am not aware of any significant differences, but you should replace the current collector with the new copy. (they should be close to identical)
I've added some minor fixes for group permissions since initial deployment. On my local machine, the collector runs as the "apache" user while the processor runs as the "breakpad" user. I had to create a group for both of the and set up config.py to set permissions at 660. Then I had to set umask 002 on the apache process because by default it was 022. I don't know how what file permissions you're planning on deploying in production, so that may not make a difference.
The config file in http://socorro.googlecode.com/svn/tags/production/a5v1/dist/processor/socorro/lib/config.py.dist mentions a processorMinidump = "/usr/local/bin/minidump_stackwalk" Where do I find this?
(In reply to comment #5) > > Where do I find this? This is my fault, for only including breakpad information in the pylons/ README. Aravind and I worked through some issues with the processor/ this evening and we discovered that I didn't export any init files for our python modules. This somehow works on my system, but shouldn't (had the same problem when morgamic initially checked out the socorro code). Since I am not sure we want to tag for deployment, we decided to punt this until tomorrow, so I can discuss with the breakpad team on irc.
http://ted.mielczarek.org/code/google-breakpad-trunk-r174.tar.bz2 contains the Google Breakpad source as of revision 174. You will need to build this source on the processor machine. ./configure && make CXXFLAGS=-O2 && make install
There is an svn tag ready to be pulled at http://socorro.googlecode.com/svn/tags/production/a5v2/dist/ with the missing __init__.py files included, and updated pylons/ directory as well.
OK, http://socorro.googlecode.com/svn/tags/production/a5v2/dist/ again. We checked this on a bare RHEL5 installation and there should be no problems.
To create the database schema: 1) Create the database 2) from a privileged account, run "CREATE LANGUAGE plpgsql;" 3) set up the pylons app and run cp production.ini setup.ini # comment out the lines that refer to proxy-prefix paster setup-app setup.ini Then, you will need to set up the partitions: psql -h <host> -U <user> <dbname> socorro/models/functions.sql psql -h <host> -U <user> <dbname> socorro/models/partitions.sql
processing dumps submitted to https://crash-reports.mozilla.com/submit You can view the reports at https://crash-reports.mozilla.com/reports
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.