Files
@ 70e29dc91deb
Branch filter:
Location: kallithea/docs/usage/troubleshooting.rst - annotation
70e29dc91deb
2.2 KiB
text/prs.fallenstein.rst
ini file: clarify that beaker.session.key should be unique
When several instances of Kallithea are running on the same machine, the
same browser cannot be logged into both instances at the same time without
conflicts. The login session are saved into the same cookie; logging into
one instance closes the session on the second instance and vice-versa.
This is caused because the cookie name is simply 'kallithea', combined with
the fact that the cookie specification (RFC6265) states that there is no
isolation of cookies based on port. This means that the browser sends all
cookies from a given domain with all services (Kallithea instances) running
on that domain, irrespective of port.
The services thus need to handle any such issue themselves, for example by
using unique cookie names and only interacting with one's own cookie.
Making the key unique when creating the configuration file proved difficult:
- it does not seem possible to hook into 'paster make-config'
- since Beaker directly interprets the beaker.session.key, changing it on
the fly from SessionMiddleware will not work correctly.
There is a kallithea-config script that is an alternative to 'paster
make-config' which would be the ideal place to make such changes. However,
it seems this method is not advocated over 'paster make-config' (yet?).
Instead, simply add a comment in the config file and let the user take care
of it.
When several instances of Kallithea are running on the same machine, the
same browser cannot be logged into both instances at the same time without
conflicts. The login session are saved into the same cookie; logging into
one instance closes the session on the second instance and vice-versa.
This is caused because the cookie name is simply 'kallithea', combined with
the fact that the cookie specification (RFC6265) states that there is no
isolation of cookies based on port. This means that the browser sends all
cookies from a given domain with all services (Kallithea instances) running
on that domain, irrespective of port.
The services thus need to handle any such issue themselves, for example by
using unique cookie names and only interacting with one's own cookie.
Making the key unique when creating the configuration file proved difficult:
- it does not seem possible to hook into 'paster make-config'
- since Beaker directly interprets the beaker.session.key, changing it on
the fly from SessionMiddleware will not work correctly.
There is a kallithea-config script that is an alternative to 'paster
make-config' which would be the ideal place to make such changes. However,
it seems this method is not advocated over 'paster make-config' (yet?).
Instead, simply add a comment in the config file and let the user take care
of it.
aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 8b8edfc25856 aa90719e8520 a9a1560dad79 8b8edfc25856 8b8edfc25856 aa90719e8520 aa90719e8520 e73a69cb98dc aa90719e8520 aa90719e8520 aa90719e8520 8b8edfc25856 aa90719e8520 aa90719e8520 e73a69cb98dc 8b8edfc25856 8b8edfc25856 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 03bbd33bc084 aa90719e8520 aa90719e8520 aa90719e8520 03bbd33bc084 aa90719e8520 aa90719e8520 8b8edfc25856 e73a69cb98dc aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 03bbd33bc084 03bbd33bc084 aa90719e8520 af2059eead28 af2059eead28 af2059eead28 03bbd33bc084 4a99684543f7 4a99684543f7 4a99684543f7 4a99684543f7 cfc0fef66ddd 03bbd33bc084 4a99684543f7 af2059eead28 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 aa90719e8520 | .. _troubleshooting:
===============
Troubleshooting
===============
:Q: **Missing static files?**
:A: Make sure either to set the `static_files = true` in the .ini file or
double check the root path for your http setup. It should point to
for example:
/home/my-virtual-python/lib/python2.7/site-packages/kallithea/public
|
:Q: **Can't install celery/rabbitmq?**
:A: Don't worry Kallithea works without them too. No extra setup is required.
Try out great celery docs for further help.
|
:Q: **Long lasting push timeouts?**
:A: Make sure you set a longer timeouts in your proxy/fcgi settings, timeouts
are caused by https server and not Kallithea.
|
:Q: **Large pushes timeouts?**
:A: Make sure you set a proper max_body_size for the http server. Very often
Apache, Nginx or other http servers kill the connection due to to large
body.
|
:Q: **Apache doesn't pass basicAuth on pull/push?**
:A: Make sure you added `WSGIPassAuthorization true`.
|
:Q: **Git fails on push/pull?**
:A: Make sure you're using an wsgi http server that can handle chunked encoding
such as `waitress` or `gunicorn`.
|
:Q: **How can I use hooks in Kallithea?**
:A: It's easy if they are python hooks just use advanced link in hooks section
in Admin panel, that works only for Mercurial. If you want to use githooks,
just install proper one in repository eg. create file in
`/gitrepo/hooks/pre-receive`. You can also use Kallithea-extensions to
connect to callback hooks, for both Git and Mercurial.
|
:Q: **Kallithea is slow for me, how can I make it faster?**
:A: See the :ref:`performance` section.
|
:Q: **UnicodeDecodeError on Apache mod_wsgi**
:A: Please read: https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/#if-you-get-a-unicodeencodeerror.
|
:Q: **Requests hanging on Windows**
:A: Please try out with disabled Antivirus software, there are some known problems with Eset Anitivirus. Make sure
you have installed latest windows patches (especially KB2789397).
.. _virtualenv: http://pypi.python.org/pypi/virtualenv
.. _python: http://www.python.org/
.. _mercurial: http://mercurial.selenic.com/
.. _celery: http://celeryproject.org/
.. _rabbitmq: http://www.rabbitmq.com/
.. _python-ldap: http://www.python-ldap.org/
|