Community Forums

1. 

   finid
   Member
   Posted 10 years ago

   So I attempted an installation on Ubuntu 13.04 server in a virtual environment (virtualenv). Everything worked ok till the deployment stage.

   I was able to start the deployment server and access the demo site, which was great.

   Past that step, I installed nginx and was able to access the default nginx site,, which is also cool.

   Now after installing a configuring uWSGI, restarting Nginx and uWSGI, I'm still getting the default Nginx site, which is not good. Could not access the site. Obviously, something was not properly configured.

   The config I used for /etc/nginx/sites-available/default is just a modified copy of the one in the guide (http://mediacorecommunity.org/docs/install/nginx-uwsgi.html).

   The [uwsgi] block in my deployment.ini reads thus:

   
[uwsgi]
socket = /tmp/uwsgi-mediacore.sock
master = true
processes = 5
home = /var/www/eckmedia
daemonize = /var/log/uwsgi.log


   The root of the installation is /var/www, with deployment.ini, data (copies from eckmedia dir), and eckmedia and mediaserve (the virtualenv) all under it.

   Here are a few lines from /var/log/uwsgi.log:

   
your server socket listen backlog is limited to 100 connections
*** Operational MODE: preforking ***
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 453)
spawned uWSGI worker 1 (pid: 454, cores: 1)
spawned uWSGI worker 2 (pid: 455, cores: 1)
spawned uWSGI worker 3 (pid: 456, cores: 1)
spawned uWSGI worker 4 (pid: 457, cores: 1)
spawned uWSGI worker 5 (pid: 458, cores: 1)


   From the above, the line that begins with "no app loaded" does not look good, does it?

   There's nothing in /var/log/nginx/access.log or error.log that tells me anything useful
   And from /var/log/
2. 

   finid
   Member
   Posted 10 years ago

   Ok, so I gave the Apache/mod_wsgi a try, but it still does not work.

   In the Apache/mod_wsgi section of the installation guide, when you said in "Note 2" that"

   If MediaCore CE should run at the URL root (no subdirectory), just remove the references to /my_media entirely.

   Does that mean removing just any occurrence of /my_media or everything next to it. For example:

   If the line is:

   <br />
   AliasMatch /my_media/images/(media|podcasts)(.*) /path/to/data/images/$1$2<br />

   Should it become:

   <br />
   AliasMatch /path/to/data/images/$1$2<br />

   Or

   <br />
   AliasMatch /images/(media|podcasts)(.*) /path/to/data/images/$1$2<br />
3. 

   Felix Schwarz
   MediaDrop developer
   Posted 10 years ago

   I don't have a MediaCore uwsgi install for experiments right now but for mod_wsgi your #2 is right:

   
AliasMatch /images/(media|podcasts)(.*) /path/to/data/images/$1$2


   But if you like, just leave out all the Alias/AliasMatch options and just put the stuff in until (including) WSGIScriptAlias. The alias stuff is mostly optimization so that Apache serves static resources directly.
4. 

   finid
   Member
   Posted 10 years ago

   tank you.

   I'm just at the tail end of this. Hopefully, should get it working soon.

   Here's where I am right now (fresh installation of Ubuntu 12.04, with Apache).

   MediaCore installed in /var/www/eckmedia, with virtualenv = /var/www/virtualeck

   deployment.ini, data, mediacore.wsgi in /var/www, right next to eckmedia and virtualeck

   Note that I installed uWSGI using "pip install uwsgi" in the virtualenv, so the executable is in /var/www/virtualeck/bin/uwsgi. Is this correct, or should I have installed it system-wide, using "apt-get install"?

   Did a backup of /etc/apache2/sites-available/default, then edited default to look like this:

   
<VirtualHost *:80>
ServerAdmin webmaster@localhost # This line from the original file

   # For best performance the number of processes should equal the number of CPU
   # cores (but please note that each process may use about 500 MB RAM).
   WSGIDaemonProcess mcore \
   processes=2 \
   threads=1 \
   display-name=%{GROUP} \
   python-path=/var/www/virtualeck/lib/python2.7/site-packages \
   python-eggs=/var/www/data/python-egg-cache

   WSGIProcessGroup mcore

   # Intercept all requests to / and pass them to mediacore.wsgi
   WSGIScriptAlias / /var/www/mediacore.wsgi

   # Make all the static content accessible
   <Directory /var/www/eckmedia/mediacore/public/*>
   Order allow,deny
   Allow from all
   Options -Indexes
   </Directory>

   ### From here starts directives from the original default file
   DocumentRoot /var/www
   <Directory />
   Options FollowSymLinks
   AllowOverride None
   </Directory>
   <Directory /var/www/>
   Options Indexes FollowSymLinks MultiViews
   AllowOverride None
   Order allow,deny
   allow from all
   </Directory>

   ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
   <Directory "/usr/lib/cgi-bin">
   AllowOverride None
   Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
   Order allow,deny
   Allow from all
   </Directory>

   ErrorLog ${APACHE_LOG_DIR}/error.log

   # Possible values include: debug, info, notice, warn, error, crit,
   # alert, emerg.
   LogLevel warn

   CustomLog ${APACHE_LOG_DIR}/access.log combined

   Alias /doc/ "/usr/share/doc/"
   <Directory "/usr/share/doc/">
   Options Indexes MultiViews FollowSymLinks
   AllowOverride None
   Order deny,allow
   Deny from all
   Allow from 127.0.0.0/255.0.0.0 ::1/128
   </Directory>

   ### /End directives from the original default file

   </VirtualHost>

   Is it still necessary to retain the directives from the original "default" file or I should have just created a new default file and copied the modified directive in there?

   Last question:

   
WSGIProcessGroup mcore


   My understanding is that "mcore" is defined inside the virtualenv, and not a system-wide group in /etc/group. Is that correct? If so, where is "mcore" defined within the virtualenv?

   After running "a2ensite" and reloading Apache, I got this error message:

   
service apache2 reload
Syntax error on line 11 of /etc/apache2/sites-enabled/000-default:
Invalid command 'WSGIDaemonProcess', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.


   I think this error relates to my question about "mcore."
5. 

   Felix Schwarz
   MediaDrop developer
   Posted 10 years ago

   Just a quick (partial) answer: With Apache you should probably you mod_wsgi not uwsgi. "Invalid command 'WSGIDaemonProcess'," indicates that you did not load mod_wsgi. Also 'mcore' is just a name for the Apache config which is not reflected either in the venv or somewhere else in the system.

   For uwsgi: It doesn't really matter where you install uwsgi. System-wide should work fine provided you use the right paths in the uwsgi config.
6. 

   finid
   Member
   Posted 10 years ago

   I actually installed libapache2-mod-wsgi first, but when I got to the part of the tutorial where I had to run:

   <br />
   uwsgi --ini-paste /var/www/deployment.ini<br />

   The command is not available if the uwsgi package is not installed. Which brings up another question. How can I run that command without installing uwsgi?

   Before reloading Apache, I made sure that the uwsgi mod is loaded, and it is. Just to be doubly sure, I just ran a2enmod, and it reports it as already loaded. There is also an entry for a "uwsgi.load" under Apache's "mods-enabled." directory.

   So, is "mcore" the correct value for "WSGIDaemonProcess"?

   I've read other docs where the location of mediacore is passed to WSGIDaemonProcess.
7. 

   Felix Schwarz
   MediaDrop developer
   Posted 10 years ago

   if you want to use uwsgi I'd go with nginx. If you want to use Apache, use mod_wsgi and forget about uwsgi altogether. Basically uwsgi provides MediaCore with the WSGI interface - that job is done by mod_wsgi if you use Apache.

   'mcore' is just a name.

   The mod_wsgi install should be relatively straightforward to implement with only very few gotches (which is why I recommend that approach). If something confuses you, just let me know.
8. 

   finid
   Member
   Posted 10 years ago

   Ok, I've a better handle on the process, and I've also gotten further than in the first attempts.

   In my last attempt, everything looks ok except the site could not load (Internal server error 200). Do this entries in Apache's error log file tell you anything?

   
[error] mod_wsgi (pid=1977): Target WSGI script '/var/www/mediacore.wsgi' cannot be loaded as Python module.
[error] mod_wsgi (pid=1977): Exception occurred processing WSGI script '/var/www/mediacore.wsgi'.
[error] Traceback (most recent call last):
[error] File "/var/www/mediacore.wsgi", line 12, in <module>
[error] from paste.script.util.logging_config import fileConfig
[error] File "/usr/local/lib/python2.7/dist-packages/PasteScript-1.7.3-py2.7.egg/paste/__init__.py", line 4, in <module>
[error] import pkg_resources
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 2823, in <module>
[error] add_activation_listener(lambda dist: dist.activate())
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 710, in subscribe
[error] callback(dist)
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 2823, in <lambda>
[error] add_activation_listener(lambda dist: dist.activate())
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 2255, in activate
[error] self.insert_on(path)
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 2362, in insert_on
[error] self.check_version_conflict()
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 2401, in check_version_conflict
[error] for modname in self._get_metadata('top_level.txt'):
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 2249, in _get_metadata
[error] for line in self.get_metadata_lines(name):
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 1219, in get_metadata_lines
[error] return yield_lines(self.get_metadata(name))
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 1211, in get_metadata
[error] return self._get(self._fn(self.egg_info,name))
[error] File "/var/www/virtualeck/lib/python2.7/site-packages/distribute-0.6.34-py2.7.egg/pkg_resources.py", line 1326, in _get
[error] stream = open(path, 'rb')
[error] IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/WebError-0.10.3-py2.7.egg/EGG-INFO/top_level.txt

9. 

   finid
   Member
   Posted 10 years ago

   I saw this thread (http://ur1.ca/evqhh) after I posted.

   However, the server, which is running Ubuntu 13.04, has Python 2.7.4 installed. One of the error messages I saw after reloading Apache said that libapache*-mod-wsgi was compiled with Python 2.7.3, which differs from the runtime version (2.7.4).

   So I removed that libapache*-mod-wsgi and compiled it from source, and specifying that the correct python version be used.

   That still did not solve the problem, because the same error message showed up.
10. 

    finid
    Member
    Posted 10 years ago

    Could it be that all the stuff I installed in the virtual env were compiled with a version of Python that's different form the runtime version, just as with mod_wsgi?
11. 

    Felix Schwarz
    MediaDrop developer
    Posted 10 years ago

    Generally the versions for python executable + mod_wsgi + venv should match to minimize the chance of linking errors/API incompatibilities. However if you use the official Python/mod_wsgi binaries from Ubuntu you should be fine if only the minor version is different.

    If you're using a self-compiled Python/mod_wsgi you have to pay more attention to possible incompatibilities, which is why I always recommend to use the distro-provided stuff.

    Now I think you got confused with the Unix permissions as indicated by
    
Permission denied: '/usr/local/lib/python2.7/dist-packages/WebError-0.10.3-py2.7.egg/EGG-INFO/top_level.txt


    The first thing to check is which user MediaCore is running under (should be configured by mod_wsgi, in your case it's probably 'apache' or so). I looks like that user can not read the 'top_level.txt' file.
12. 

    Felix Schwarz
    MediaDrop developer
    Posted 10 years ago

    I just reread the mod_wsgi install docs and I noticed we don't mention anything about user permissions. That's bad.

    I always run MediaCore under a separate user account, e.g. the unix user 'mediacore'. When I create the venv, download/install the software I'm doing that as 'mediacore' (not 'root'). That prevents a lot of errors.

    To run the wsgi application as a separate user, you need to add the parameters "user=mediacore group=mediacore" to "WSGIDaemonProcess" (replace 'mediacore' with the a unix name/group of your choice).

    This provides you with an additional safety net (it is hard to mess up your system accidentally, some more hurdles for malicious code to infect the apache/the os, better isolation from other web apps).
13. 

    finid
    Member
    Posted 10 years ago

    The problem with the versions of Python is that I did not have control over it. Except for MediaCore, all packages were installed from the repo. I only compiled mod_wsgi from source after the system warned that there is a difference between the compiled and runtime versions of Python.

    But even at that, the error message was still the same.

    About file permissions and ownership, yes, nothing was said about them in the docs. Since I did the installation on a local test system, many of the steps had to be run as root, which meant that the files and folders were owned by root. However, that did not affect the loading of the development site.

    In any case, I changed ownership of all files to www-data, but that did not even solve the problem. Maybe, as you suggested, I should specify that as an option to "WSGIDaemonProcess".
14. 

    finid
    Member
    Posted 10 years ago

    Well, that didn't help. Still the same error message as before.

    Btw, there is no specific user called "mediacore" in the system, so ownership of files is www-data and specified that to WSGIDaemonProcess.
15. 

    finid
    Member
    Posted 10 years ago

    Given the first line in the error message, do you thing this has something to do with the PYTHONPATH of the user who owns the WSGI script file not being consulted?
16. 

    finid
    Member
    Posted 10 years ago

    I activated the virtual env and reran "python setup.py develop." This is the type of messages it's spewing:

    
Using /usr/local/lib/python2.7/dist-packages/nose-1.0.0-py2.7.egg
Searching for Beaker==1.5.4
Best match: Beaker 1.5.4
Processing Beaker-1.5.4-py2.7.egg
Beaker 1.5.4 is already the active version in easy-install.pth</p>


    Isn't it supposed to be using the Python in the virtualenv, rather than the system one?
17. 

    finid
    Member
    Posted 10 years ago

    Ok, got it to work. That there is a difference in the compiled and runtime versions of Python does not affect anything.

    Thanks.

RSS feed for this topic

Reply

You must log in to post.