Difference between revisions of "Spatialreference.org"

From OSGeo
Jump to navigation Jump to search
(Created page with 'SR.org lives on its own apache server to prevent it going down and taking out the rest of the projects VM. To fix it: 1. cat /var/run/srorgapache.pid for a PID File, and check t…')
 
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
'''Current info at http://trac.osgeo.org/metacrs/wiki/SpatialReferenceOrg - The following is deprecated and likely out of date.'''
 +
 +
----
 +
 +
Currently runs under gunicorn wsgi server proxied through apache.
 +
* Proxy /etc/apache/site-available/sr.org.conf
 +
* Service can be controlled via /etc/init.d/gunicorn
 +
* Configuration file /etc/gunicorn.d/sr.gunicorn (
 +
** Port 8092
 +
** workers=4 (Can be modified, gunicorn recommends 2-4x # of cores (which is 4), but I lowered it to see if it plays better with the existing services.)
 +
* Gunicorn is installed via backports
 +
 +
''The notes below are for the previous method which is still installed but currently disabled:''
 
SR.org lives on its own apache server to prevent it going down and taking out the rest of the projects VM. To fix it:
 
SR.org lives on its own apache server to prevent it going down and taking out the rest of the projects VM. To fix it:
  
1. cat /var/run/srorgapache.pid for a PID File, and check that that pid is an apache2 file running with the srorg config (using grep).  
+
* cat /var/run/srorgapache.pid for a PID File, and check that that pid is an apache2 file running with the srorg config (using grep).  
2. Kill this process.
+
* Kill this process.
3. Run /etc/init.d/srorgapache start
+
* Run /etc/init.d/srorgapache start
  
 
This weird process is a side effect of how the srorgapache init.d script is written; because it is the same process name (apache2), the apache init script will kill the main projects VM if you just run restart.
 
This weird process is a side effect of how the srorgapache init.d script is written; because it is the same process name (apache2), the apache init script will kill the main projects VM if you just run restart.
  
 
The server runs on port 8090; it takes about one minute to become available after the server is started. You can access it directly at http://spatialreference.org:8090, and http://spatialreference.org is proxied through the main apache.
 
The server runs on port 8090; it takes about one minute to become available after the server is started. You can access it directly at http://spatialreference.org:8090, and http://spatialreference.org is proxied through the main apache.

Latest revision as of 13:05, 22 March 2013

Current info at http://trac.osgeo.org/metacrs/wiki/SpatialReferenceOrg - The following is deprecated and likely out of date.


Currently runs under gunicorn wsgi server proxied through apache.

  • Proxy /etc/apache/site-available/sr.org.conf
  • Service can be controlled via /etc/init.d/gunicorn
  • Configuration file /etc/gunicorn.d/sr.gunicorn (
    • Port 8092
    • workers=4 (Can be modified, gunicorn recommends 2-4x # of cores (which is 4), but I lowered it to see if it plays better with the existing services.)
  • Gunicorn is installed via backports

The notes below are for the previous method which is still installed but currently disabled: SR.org lives on its own apache server to prevent it going down and taking out the rest of the projects VM. To fix it:

  • cat /var/run/srorgapache.pid for a PID File, and check that that pid is an apache2 file running with the srorg config (using grep).
  • Kill this process.
  • Run /etc/init.d/srorgapache start

This weird process is a side effect of how the srorgapache init.d script is written; because it is the same process name (apache2), the apache init script will kill the main projects VM if you just run restart.

The server runs on port 8090; it takes about one minute to become available after the server is started. You can access it directly at http://spatialreference.org:8090, and http://spatialreference.org is proxied through the main apache.