Re: [galaxy-dev] Starting uWSGI

2015-02-02 Thread Nicholas Kline
Hi Nate. Thanks a lot for all the help so far. So, I started uWSGI like so:

- activate virtual env
- cd ~/galaxy-dist
- PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
universe_wsgi.ini

Then browsed to localhost, which redirected to https://localhost/ as
expected since I want all traffic to be over HTTPS, and finally
returned:

502 Bad Gateway

I checked uwsgi.log and it's quite large, almost 3,000 lines. Should I
post it to this list for review? I've included the last few lines
below:

*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 4083)
spawned uWSGI worker 1 (pid: 4195, cores: 4)
spawned uWSGI worker 2 (pid: 4199, cores: 4)
spawned uWSGI worker 3 (pid: 4203, cores: 4)
spawned uWSGI worker 4 (pid: 4207, cores: 4)
spawned uWSGI worker 5 (pid: 4211, cores: 4)
spawned uWSGI worker 6 (pid: 4215, cores: 4)
spawned uWSGI worker 7 (pid: 4219, cores: 4)
spawned uWSGI worker 8 (pid: 4223, cores: 4)
spawned uWSGI worker 9 (pid: 4224, cores: 4)
spawned uWSGI worker 10 (pid: 4225, cores: 4)
*** Stats server enabled on 127.0.0.1:9191 fd: 30 ***
Traceback (most recent call last):
  File /home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlmap.py,
line 201, in __call__
environ['SCRIPT_NAME'] += app_url
KeyError: 'SCRIPT_NAME'
[pid: 4219|app: 0|req: 1/1] 127.0.0.1 () {40 vars in 593 bytes} [Fri
Jan 30 15:15:10 2015] GET / = generated 0 bytes in 18 msecs (HTTP/1.1
500) 0 headers in 0 bytes (0 switches on core 0)

If you need me to post my Nginx config too, just let me know. Thanks!



On Wed, Jan 28, 2015 at 2:53 PM, Nate Coraor n...@bx.psu.edu wrote:
 On Wed, Jan 28, 2015 at 11:55 AM, Nicholas Kline nx...@case.edu wrote:

 Hi Nate. Thank you for the reply. So I installed uWSGI inside my
 Python virtual environment since that was one of the options listed in
 the documentation, like so:

 cd ~/galaxy_env/
 source bin/activate
 pip install uwsgi

 It looks like uWSGI was successfully installed. I then
 exited/deactivated the virtual environment via 'deactivate'.

 Next, I tried to start uWSGI:

 ~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
 --ini-paste config/galaxy.ini


 Calling uwsgi after deactivating the virtualenv means it'd be running from
 wherever it's found on $PATH, which is probably not the one you just
 installed into the virtualenv. But if it works, it may not matter.



 ... but it returned this:


 realpath() of config/galaxy.ini failed: No such file or directory
 [core/utils.c line 3607]

 So, I pointed it to universe_wsgi.ini instead, like so:

 ~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
 --ini-paste universe_wsgi.ini


 universe_wsgi.ini was renamed to config/galaxy.ini late last year. However,
 if you still have it, it's perfectly fine to leave it there and continue
 using it.



 ...and this was returned:

 [uWSGI] getting INI configuration from universe_wsgi.ini

 At that point, Terminal just kinda sits there and does not display any
 output, error messages, etc.


 If uwsgi is running, this suggests it's working. If you have set up the
 uwsgi proxy in nginx you should be able to try to access Galaxy via the web
 at this point. More detail may be available in the uwsgi log file - did you
 set `logto` in the `[uwsgi]` section of universe_wsgi.ini?


 Questions:

 1. Was I correct in specifying universe_wsgi.ini ?


 The location of the config file is up to you. universe_wsgi.ini in the root
 of the Galaxy directory was the old default.


 2. Nothing is returned after [uWSGI] getting INI configuration from
 universe_wsgi.ini. Is that normal?


 Yes. You probably want to set `logto` as described above and start uwsgi in
 the background, e.g. with the `-d` command line option.

 3. Should I activate the Python virtual environment first (via source
 bin/activate) before executing ~/galaxy-dist$
 PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
 universe_wsgi.ini ?


 Yes, I would do this.


 4. Is the next step to start Galaxy, like so?

 cd galaxy-dist
 GALAXY_RUN_ALL=1 sh run.sh --daemon


 uwsgi is running your Galaxy web processes, so I would check to ensure they
 are working first. Once you've verified that, you can use the command above
 to start any job handlers you have configured.

 --nate



 I appreciate your help.




 On Mon, Jan 26, 2015 at 5:22 PM, Nate Coraor n...@bx.psu.edu wrote:
  Hi Nicholas,
 
  Sorry for the somewhat misleading text in the documentation. The part
  about
  no extra modules or recompiling refers to nginx itself - uWSGI
  protocol
  support is built in to the core functionality of nginx. This does not
  mean
  that uWSGI itself is installed. Installing uWSGI is addressed a bit
  further
  up:
 
  You will also need to have uWSGI installed. There are a variety of ways
  to
  do this. It can be installed system-wide by installing from your
  system's
  package manager (on Debian and Ubuntu systems, 

Re: [galaxy-dev] Starting uWSGI

2015-02-02 Thread Nate Coraor
Hi Nicholas,

Set `static_enabled = False` in universe_wsgi.ini and restart uWSGI, and
see if that makes a difference.

Thanks,
--nate

On Mon, Feb 2, 2015 at 11:26 AM, Nicholas Kline nx...@case.edu wrote:

 Hi Nate. Thanks a lot for all the help so far. So, I started uWSGI like so:

 - activate virtual env
 - cd ~/galaxy-dist
 - PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
 universe_wsgi.ini

 Then browsed to localhost, which redirected to https://localhost/ as
 expected since I want all traffic to be over HTTPS, and finally
 returned:

 502 Bad Gateway

 I checked uwsgi.log and it's quite large, almost 3,000 lines. Should I
 post it to this list for review? I've included the last few lines
 below:

 *** uWSGI is running in multiple interpreter mode ***
 spawned uWSGI master process (pid: 4083)
 spawned uWSGI worker 1 (pid: 4195, cores: 4)
 spawned uWSGI worker 2 (pid: 4199, cores: 4)
 spawned uWSGI worker 3 (pid: 4203, cores: 4)
 spawned uWSGI worker 4 (pid: 4207, cores: 4)
 spawned uWSGI worker 5 (pid: 4211, cores: 4)
 spawned uWSGI worker 6 (pid: 4215, cores: 4)
 spawned uWSGI worker 7 (pid: 4219, cores: 4)
 spawned uWSGI worker 8 (pid: 4223, cores: 4)
 spawned uWSGI worker 9 (pid: 4224, cores: 4)
 spawned uWSGI worker 10 (pid: 4225, cores: 4)
 *** Stats server enabled on 127.0.0.1:9191 fd: 30 ***
 Traceback (most recent call last):
   File
 /home/galaxy/galaxy-dist/eggs/Paste-1.7.5.1-py2.7.egg/paste/urlmap.py,
 line 201, in __call__
 environ['SCRIPT_NAME'] += app_url
 KeyError: 'SCRIPT_NAME'
 [pid: 4219|app: 0|req: 1/1] 127.0.0.1 () {40 vars in 593 bytes} [Fri
 Jan 30 15:15:10 2015] GET / = generated 0 bytes in 18 msecs (HTTP/1.1
 500) 0 headers in 0 bytes (0 switches on core 0)

 If you need me to post my Nginx config too, just let me know. Thanks!



 On Wed, Jan 28, 2015 at 2:53 PM, Nate Coraor n...@bx.psu.edu wrote:
  On Wed, Jan 28, 2015 at 11:55 AM, Nicholas Kline nx...@case.edu wrote:
 
  Hi Nate. Thank you for the reply. So I installed uWSGI inside my
  Python virtual environment since that was one of the options listed in
  the documentation, like so:
 
  cd ~/galaxy_env/
  source bin/activate
  pip install uwsgi
 
  It looks like uWSGI was successfully installed. I then
  exited/deactivated the virtual environment via 'deactivate'.
 
  Next, I tried to start uWSGI:
 
  ~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
  --ini-paste config/galaxy.ini
 
 
  Calling uwsgi after deactivating the virtualenv means it'd be running
 from
  wherever it's found on $PATH, which is probably not the one you just
  installed into the virtualenv. But if it works, it may not matter.
 
 
 
  ... but it returned this:
 
 
  realpath() of config/galaxy.ini failed: No such file or directory
  [core/utils.c line 3607]
 
  So, I pointed it to universe_wsgi.ini instead, like so:
 
  ~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
  --ini-paste universe_wsgi.ini
 
 
  universe_wsgi.ini was renamed to config/galaxy.ini late last year.
 However,
  if you still have it, it's perfectly fine to leave it there and continue
  using it.
 
 
 
  ...and this was returned:
 
  [uWSGI] getting INI configuration from universe_wsgi.ini
 
  At that point, Terminal just kinda sits there and does not display any
  output, error messages, etc.
 
 
  If uwsgi is running, this suggests it's working. If you have set up the
  uwsgi proxy in nginx you should be able to try to access Galaxy via the
 web
  at this point. More detail may be available in the uwsgi log file - did
 you
  set `logto` in the `[uwsgi]` section of universe_wsgi.ini?
 
 
  Questions:
 
  1. Was I correct in specifying universe_wsgi.ini ?
 
 
  The location of the config file is up to you. universe_wsgi.ini in the
 root
  of the Galaxy directory was the old default.
 
 
  2. Nothing is returned after [uWSGI] getting INI configuration from
  universe_wsgi.ini. Is that normal?
 
 
  Yes. You probably want to set `logto` as described above and start uwsgi
 in
  the background, e.g. with the `-d` command line option.
 
  3. Should I activate the Python virtual environment first (via source
  bin/activate) before executing ~/galaxy-dist$
  PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
  universe_wsgi.ini ?
 
 
  Yes, I would do this.
 
 
  4. Is the next step to start Galaxy, like so?
 
  cd galaxy-dist
  GALAXY_RUN_ALL=1 sh run.sh --daemon
 
 
  uwsgi is running your Galaxy web processes, so I would check to ensure
 they
  are working first. Once you've verified that, you can use the command
 above
  to start any job handlers you have configured.
 
  --nate
 
 
 
  I appreciate your help.
 
 
 
 
  On Mon, Jan 26, 2015 at 5:22 PM, Nate Coraor n...@bx.psu.edu wrote:
   Hi Nicholas,
  
   Sorry for the somewhat misleading text in the documentation. The part
   about
   no extra modules or recompiling refers to nginx itself - uWSGI
   protocol
   support is 

Re: [galaxy-dev] Starting uWSGI

2015-01-28 Thread Nicholas Kline
Hi Nate. Thank you for the reply. So I installed uWSGI inside my
Python virtual environment since that was one of the options listed in
the documentation, like so:

cd ~/galaxy_env/
source bin/activate
pip install uwsgi

It looks like uWSGI was successfully installed. I then
exited/deactivated the virtual environment via 'deactivate'.

Next, I tried to start uWSGI:

~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
--ini-paste config/galaxy.ini

... but it returned this:

realpath() of config/galaxy.ini failed: No such file or directory
[core/utils.c line 3607]

So, I pointed it to universe_wsgi.ini instead, like so:

~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
--ini-paste universe_wsgi.ini

...and this was returned:

[uWSGI] getting INI configuration from universe_wsgi.ini

At that point, Terminal just kinda sits there and does not display any
output, error messages, etc.

Questions:

1. Was I correct in specifying universe_wsgi.ini ?

2. Nothing is returned after [uWSGI] getting INI configuration from
universe_wsgi.ini. Is that normal?

3. Should I activate the Python virtual environment first (via source
bin/activate) before executing ~/galaxy-dist$
PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
universe_wsgi.ini ?

4. Is the next step to start Galaxy, like so?

cd galaxy-dist
GALAXY_RUN_ALL=1 sh run.sh --daemon

I appreciate your help.




On Mon, Jan 26, 2015 at 5:22 PM, Nate Coraor n...@bx.psu.edu wrote:
 Hi Nicholas,

 Sorry for the somewhat misleading text in the documentation. The part about
 no extra modules or recompiling refers to nginx itself - uWSGI protocol
 support is built in to the core functionality of nginx. This does not mean
 that uWSGI itself is installed. Installing uWSGI is addressed a bit further
 up:

 You will also need to have uWSGI installed. There are a variety of ways to
 do this. It can be installed system-wide by installing from your system's
 package manager (on Debian and Ubuntu systems, the uwsgi and
 uwsgi-plugin-python provide the necessary components), or with
 theeasy_install or pip commands (which will install it to the system's
 Python site-packages directory). Alternatively, if you are already running
 Galaxy from a Python virtualenv, you can use pip install uwsgi with that
 virtualenv's copy of pip to install to that virtualenv as your unprivileged
 Galaxy user.


 In the case of Ubuntu sudo apt-get install uwsgi uwsgi-plugin-python  should
 provide the necessary components.

 --nate

 On Mon, Jan 26, 2015 at 2:46 PM, Nicholas Kline nx...@case.edu wrote:

 Hello,

 I am trying to setup a local production Galaxy server for our
 department. Our Galaxy server environment is as follows:

 - Ubuntu 14.04 64-bit
 - 94 GB Memory
 - Intel Xeon
 - Python virtual environment
 - Nginx
 - PostgreSQL
 - ProFTPd

 Today I tried starting the Galaxy server for the first time. I think
 the first step in that process is starting uWSGI, correct? To do so, I
 executed these commands:

 cd ~/galaxy-dist/
 PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
 config/galaxy.ini

 However, it appears something failed. This information is returned:

 The program 'uwsgi' can be found in the following packages:
  * uwsgi-core
  * uwsgi-plugin-alarm-curl
  * uwsgi-plugin-alarm-xmpp
  * uwsgi-plugin-curl-cron
  * uwsgi-plugin-emperor-pg
  * uwsgi-plugin-erlang
  * uwsgi-plugin-geoip
  * uwsgi-plugin-graylog2
  * uwsgi-plugin-jvm-openjdk-6
  * uwsgi-plugin-jvm-openjdk-7
  * uwsgi-plugin-ldap
  * uwsgi-plugin-lua5.1
  * uwsgi-plugin-lua5.2
  * uwsgi-plugin-php
  * uwsgi-plugin-psgi
  * uwsgi-plugin-python
  * uwsgi-plugin-python3
  * uwsgi-plugin-rack-ruby1.9.1
  * uwsgi-plugin-router-access
  * uwsgi-plugin-sqlite3
  * uwsgi-plugin-v8
  * uwsgi-plugin-xslt
 Ask your administrator to install one of them

 According to the galaxy documentation at
 https://wiki.galaxyproject.org/Admin/Config/Performance/Scaling ,
 uWSGI support is built in to nginx, so no extra modules or
 recompiling should be required.

 Also, should '--ini-paste config/galaxy.ini' really be configured like
 this instead: --ini-paste universe_wsgi.ini ?

 Thank you
 ___
 Please keep all replies on the list by using reply all
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
   https://lists.galaxyproject.org/

 To search Galaxy mailing lists use the unified search at:
   http://galaxyproject.org/search/mailinglists/


___
Please keep all replies on the list by using reply all
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Starting uWSGI

2015-01-28 Thread Nate Coraor
On Wed, Jan 28, 2015 at 11:55 AM, Nicholas Kline nx...@case.edu wrote:

 Hi Nate. Thank you for the reply. So I installed uWSGI inside my
 Python virtual environment since that was one of the options listed in
 the documentation, like so:

 cd ~/galaxy_env/
 source bin/activate
 pip install uwsgi

 It looks like uWSGI was successfully installed. I then
 exited/deactivated the virtual environment via 'deactivate'.

 Next, I tried to start uWSGI:

 ~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
 --ini-paste config/galaxy.ini


Calling uwsgi after deactivating the virtualenv means it'd be running from
wherever it's found on $PATH, which is probably not the one you just
installed into the virtualenv. But if it works, it may not matter.



 ... but it returned this:


 realpath() of config/galaxy.ini failed: No such file or directory
 [core/utils.c line 3607]

 So, I pointed it to universe_wsgi.ini instead, like so:

 ~/galaxy-dist$ PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi
 --ini-paste universe_wsgi.ini


universe_wsgi.ini was renamed to config/galaxy.ini late last year. However,
if you still have it, it's perfectly fine to leave it there and continue
using it.



 ...and this was returned:

 [uWSGI] getting INI configuration from universe_wsgi.ini

 At that point, Terminal just kinda sits there and does not display any
 output, error messages, etc.


If uwsgi is running, this suggests it's working. If you have set up the
uwsgi proxy in nginx you should be able to try to access Galaxy via the web
at this point. More detail may be available in the uwsgi log file - did you
set `logto` in the `[uwsgi]` section of universe_wsgi.ini?


 Questions:

 1. Was I correct in specifying universe_wsgi.ini ?


The location of the config file is up to you. universe_wsgi.ini in the root
of the Galaxy directory was the old default.


 2. Nothing is returned after [uWSGI] getting INI configuration from
 universe_wsgi.ini. Is that normal?


Yes. You probably want to set `logto` as described above and start uwsgi in
the background, e.g. with the `-d` command line option.

3. Should I activate the Python virtual environment first (via source
 bin/activate) before executing ~/galaxy-dist$
 PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
 universe_wsgi.ini ?


Yes, I would do this.


 4. Is the next step to start Galaxy, like so?

 cd galaxy-dist
 GALAXY_RUN_ALL=1 sh run.sh --daemon


uwsgi is running your Galaxy web processes, so I would check to ensure they
are working first. Once you've verified that, you can use the command above
to start any job handlers you have configured.

--nate



 I appreciate your help.




 On Mon, Jan 26, 2015 at 5:22 PM, Nate Coraor n...@bx.psu.edu wrote:
  Hi Nicholas,
 
  Sorry for the somewhat misleading text in the documentation. The part
 about
  no extra modules or recompiling refers to nginx itself - uWSGI protocol
  support is built in to the core functionality of nginx. This does not
 mean
  that uWSGI itself is installed. Installing uWSGI is addressed a bit
 further
  up:
 
  You will also need to have uWSGI installed. There are a variety of ways
 to
  do this. It can be installed system-wide by installing from your
 system's
  package manager (on Debian and Ubuntu systems, the uwsgi and
  uwsgi-plugin-python provide the necessary components), or with
  theeasy_install or pip commands (which will install it to the system's
  Python site-packages directory). Alternatively, if you are already
 running
  Galaxy from a Python virtualenv, you can use pip install uwsgi with that
  virtualenv's copy of pip to install to that virtualenv as your
 unprivileged
  Galaxy user.
 
 
  In the case of Ubuntu sudo apt-get install uwsgi uwsgi-plugin-python
 should
  provide the necessary components.
 
  --nate
 
  On Mon, Jan 26, 2015 at 2:46 PM, Nicholas Kline nx...@case.edu wrote:
 
  Hello,
 
  I am trying to setup a local production Galaxy server for our
  department. Our Galaxy server environment is as follows:
 
  - Ubuntu 14.04 64-bit
  - 94 GB Memory
  - Intel Xeon
  - Python virtual environment
  - Nginx
  - PostgreSQL
  - ProFTPd
 
  Today I tried starting the Galaxy server for the first time. I think
  the first step in that process is starting uWSGI, correct? To do so, I
  executed these commands:
 
  cd ~/galaxy-dist/
  PYTHONPATH=eggs/PasteDeploy-1.5.0-py2.7.egg uwsgi --ini-paste
  config/galaxy.ini
 
  However, it appears something failed. This information is returned:
 
  The program 'uwsgi' can be found in the following packages:
   * uwsgi-core
   * uwsgi-plugin-alarm-curl
   * uwsgi-plugin-alarm-xmpp
   * uwsgi-plugin-curl-cron
   * uwsgi-plugin-emperor-pg
   * uwsgi-plugin-erlang
   * uwsgi-plugin-geoip
   * uwsgi-plugin-graylog2
   * uwsgi-plugin-jvm-openjdk-6
   * uwsgi-plugin-jvm-openjdk-7
   * uwsgi-plugin-ldap
   * uwsgi-plugin-lua5.1
   * uwsgi-plugin-lua5.2
   * uwsgi-plugin-php
   * uwsgi-plugin-psgi
   *