# Radicale usage on a Debian system

Radicale can be started either in a user session or system-wide,
handling authentication itself or off-loading to a front-end service.

Radicale in Debian by default uses authentication scheme "remote_user",
i.e. expects a front-end web service to resolve ${REMOTE_USER} via WSGI.


## Apache via uWSGI with PAM authentication

Recommended setup for production use is to serve system-wide
by Apache via uWSGI with Apache-based authenticating,
using the file /etc/radicale/config as main configuration file.

Install needed packages:

	apt install uwsgi uwsgi-plugin-python3 apache2 libapache2-mod-authnz-external

Enable and activate back-end uWSGI service:

	ln -st /etc/uwsgi/apps-enabled/ ../apps-available/radicale.ini
	service uwsgi restart

Setup, enable, and activate front-end service
(details on vhost and SSL/TLS certificate setup is not covered here):

	a2enmod proxy_uwsgi ssl
	cp /usr/share/doc/radicale/examples/apache2-vhost.conf /etc/apache2/sites-available/events.example.org.conf
	a2ensite events.example.org.conf
	service apache2 restart


## Simple daemon

It should be possible to serve directly with sysV management,
although this is discouraged and not well tested.

Edit /etc/radicale/config to adapt as needed,
e.g. change in [auth] section to something else than "remote_user".

Activate init script:

	update-rc.d radicale enable


## Limit memory consumption

When using uWSGI middleware with several threads or processes,
memory can be reduced at the expense of CPU use.

Edit /etc/uwsgi/apps-enabled/radicale.ini, enabling ksm.

Enable needed packages:

	apt install sysfsutils

Activate detection and auto-merging of identical memory pages:

	echo "kernel/mm/ksm/run = 1" >> /etc/sysfs.d/local-ksm.conf
	service sysfsutils restart
	service uwsgi reload

See /etc/uwsgi/apps-enabled/radicale.ini for other tuning opportunities.


 -- Jonas Smedegaard <dr@jones.dk>  Wed, 12 Dec 2018 15:51:06 +0100