anthonygego on cookieless_fix
cookieless: do not hardcode lti… (compare)
anthonygego on master
Add information about setup and… Merge pull request #688 from da… (compare)
anthonygego on master
Update submissions.html Merge pull request #686 from UC… (compare)
anthonygego on issue-684
@anthonygego I am trying to setup INGINious inside a docker container. I can figure out how to allow access to the host docker daemon, but I am having some trouble with routing web traffic. A friend of mine recommend gunicorn, but getting gunicorn to serve INGInious properly has proven to be a hassle. INGInious seems to want to server its own content. Gunicorn will listen on port 8000, but for some reason (even after removing all of the main code in the 0.4 relase) INGInious runs its own webserver on 8080 within the container. Any advice on how to make this process work?
My ideal situation is that nginx will route traffic to the gunicorn server in my container, which acts as a reverse proxy for INGInious. If you feel this isn't an optimal setup,I am definitely up for suggestions.I am handing off the INGInious project to someone else at my university in a few months, and I want the setup/deployment strategy to be easy to understand and most importantly scriptable.
@jamesrobb there is a problem with the detection of FCGI in the code. I'll open an issue. What you can do in the meantime is to copy the content of the file
inginious-webapp.py into another file, say
wsgi.py, and remove the lines
if 'SERVER_SOFTWARE' in os.environ: # cgi os.environ['FCGI_FORCE_CGI'] = 'Y' if 'PHP_FCGI_CHILDREN' in os.environ or 'SERVER_SOFTWARE' in os.environ: # lighttpd fastcgi print(os.environ) import flup.server.fcgi as flups flups.WSGIServer(application, multiplexed=True, bindAddress=None, debug=False).run()
(which handle the fastcgi detection), then call
I'd like to automate some testing for my deployment of INGInious. In particular, we had the system crash last year during a class where lots of students were using the system at the same time .
I can pull the submissions out of the mongo database, but I am wondering if there is some sort of API call (or something similar) that I can make against INGInious to run these submissions. My idea is to use some testing software to keep asking INGInious to run these various submissions to see where and how things broke down.
Any idea @GuillaumeDerval how I can do this?
ssh_exchange_identification: read: Connection reset by peer
When i'm running:
Collecting git+https://github.com/UCL-INGI/INGInious.git Cloning https://github.com/UCL-INGI/INGInious.git to /tmp/pip-req-build-bn7e7jp7 Complete output from command python setup.py egg_info: Traceback (most recent call last): File "<string>", line 1, in <module> File "/tmp/pip-req-build-bn7e7jp7/setup.py", line 85, in <module> long_description=open(os.path.join(os.path.dirname(__file__), 'README.rst')).read() File "/usr/lib64/python3.5/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors) UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 637: ordinal not in range(128)
pip3.5 install --upgrade git+https://github.com/UCL-INGI/INGInious.git
hello, i have trouble with accessing student submissions from single task. Specifically it is page /admin/6m/submissions?user=studentname&task=posloupnost-max-rust . Page says "internal server error". Log says:
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 22233: ordinal not in range(128), referer: https://inginious.hamiweb.cz/admin/6m/task/posloupnost-max-rust
This error occours with every student on any task even if they dont have any submissions for the task yet. I can download submissions without problem, i just cannot view them. I am on the latest 0.5 inginious. Should i open new issue? I just wanted to make sure here i am not doing something stupid.
Hello @hamacekh are you using apache?
I am seeing UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 22233: ordinal not in range(128) which prevents a plugin from being loaded. This DOES NOT HAPPEN on the development version. i.e. I stop the apache service and run inginious in debug mode (inginious-webap --host 0.0.0.0 --port 80) and the issue does not happen and the plugin is loaded correctly
I haven't found any solution yet but I think it is related to apache and python integration because it does not happen on development mode (not using apache).
@hamacekh I have found the error, I don't know if it would work for your case but I might be worth a look.
What happened is that for some reason we had and environment variable called LANG set to C (ascii) default encoding for apache. The solution is simply to eliminate it so that it will use default setting form the OS.
If you don't have that variable you might need to set it to the encoding you want or edit the locales of your server
On CentOS they are located on
On Ubuntu they are located on
Here are some useful links that explain the issue