#872816 radicale wsgi example not usable

Package:
radicale
Source:
radicale
Submitter:
Joerg Dorchain
Date:
2026-03-14 01:01:01 UTC
Severity:
normal
#872816#5
Date:
2017-08-21 14:42:41 UTC
From:
To:
Hello,

when trying to use the supplied /usr/share/radicale/radicale.wsgi
file with libapache2-mod-wsgi     4.5.17-1, the following error
is displayed in the apache error log:

 SyntaxError: Non-ASCII character '\\xc2' in file
 .../radicale.wsgi on line 4, but no encoding declared; see
http://python.org/dev/peps/pep-0263/ for details

Externally a 500 internal error is shown.

Inserting # coding: utf-8 as second line solves it for me.

Bye,

Joerg
#872816#10
Date:
2017-08-21 15:51:07 UTC
From:
To:
Quoting Joerg Dorchain (2017-08-21 16:42:41)

Apparently libapache2-mod-wsgi is more picky than uwsgi which I use
myself - that's the reason I wasn't aware of this.

You might want to consider uwsgi: I believe with libapache2-mod-wsgi all
data will be writable by the www-data user, which might be a problem if
you host more than a single application on your server.


 - Jonas
#872816#15
Date:
2017-08-21 16:16:34 UTC
From:
To:
Obviously to be completely correct it the libapache2-mod-wsgi-py3
package.

While at the file, it empties out the config path
(/etc/radicale/config) which might or might be be intented.  IMHO
it should use the default path, i.e. a line config_paths =
["/etc/radicale/config"].
It would be worth mentioned it in a README.debian, what ever it
will be.

Yes, libapache2-mod-wsgi runs as the apache user. For my small
setup, this is fine, but thanks for the hint!

On a background, I started completely revamping a radicale setup
originating even before the debian package. Many things are
historically grown features.

Bye,

Joerg
#872816#20
Date:
2017-08-21 16:54:08 UTC
From:
To:
Quoting Joerg Dorchain (2017-08-21 18:16:34)

Upstream WSGI file is shipped as-is.  Would you mind bringing these
issues upstream yourself?

Ohh, such examination sometimes reveal interesting stuff.  Please do
keep me (and upstream) posted about any findings of yours!


 - Jonas
#872816#25
Date:
2017-08-21 17:15:11 UTC
From:
To:
https://github.com/Kozea/Radicale/issues/685

I filed another bug about a missing dependancy.

Now I am reviewing my authorisation system, which used to be based
on apache and some mod_rewrite magic, and try to see how far I get
with methods available from within radicale.

Bye,

Joerg
#872816#30
Date:
2017-08-23 12:54:38 UTC
From:
To:
Upstream support pointed me to proper use of apache2 envvars:

- I had an historic entry for the LANG setting there, causing
  problems with the non-ascii char.

- Also the offical way of pointing the wsgi version to its config
  file is via environment variable, which again for me leads to
  apache envvars.
  This point is probably worth mentioning in a README{.debian}

With pleasure!

Bye,

Joerg
#872816#35
Date:
2017-08-23 22:27:56 UTC
From:
To:
Quoting Joerg Dorchain (2017-08-23 14:54:38)

I prefer to leave WSGI documentation generally to external resources.

I'd be happy to include sample config snippets for mod_wsgi (and nginx
and uwsgi and other web servers) with the Debian radicale package.

Can you provide me a file to place below /etc/apache2/sites-available/
then I can use that as basis.


 - Jonas
#872816#40
Date:
2017-08-24 07:22:24 UTC
From:
To:
To me this is a radicale specific hint. The rest of the
documentation talks about config in /etc/radcale/config, but to
my big surprise the supplied wsgi script explicitly disables it.

It is not quite that easy, however let's try with some snippets.

My working config of radicale with the supplied wsgi script
consists of the following config snippets:

- in /etc/apache2/envvars
# Make sure mod_wsgi has utf-8 as default encodig. There are other
# ways to achive this, this sets it for all of apache (including e.g.
# php), which is fine for me.
export LANG=C.UTF-8
# Pointing the wsgi version of radicale to its config
# Upstream explicitly removes the normal path in the supplied wsgi
# script.
export RADICALE_CONFIG=/etc/radicale/config

- in the apache config file for the (virtual) host:
# You can choose a different user here, e.g. radicale
WSGIDaemonProcess radicale user=www-data group=www-data threads=9 inactivity-timeout=300 display-name=%{GROUP}
# If you have a decidate vhost use / here.
WSGIScriptAlias /caldav /usr/share/radicale/radicale.wsgi
<Location "/caldav">
    WSGIProcessGroup radicale
    WSGIApplicationGroup %{GLOBAL}
# When you have in /etc/radicale/config in section [auth]
# type=remote, leave this commented out
#    WSGIPassAuthorization On
    AllowOverride None

# Leave Authentication to Apache, which makes most sense with
# type=remote authentication in radicale
    AuthType Basic
    AuthName "radicale"
    AuthBasicProvider file
    AuthUserFile  /etc/apache2/caldav-passwd
    Require valid-user
</Location>

Bye,

Joerg
#872816#45
Date:
2017-08-24 11:33:05 UTC
From:
To:
Hi Jonas,

I'm running radicale via uwsgi and nginx, are you interested in the
configs, in another bug?

Cheers,
Georg
#872816#50
Date:
2017-08-24 12:47:52 UTC
From:
To:
https://github.com/Kozea/Radicale/issues/685,
https://gist.github.com/return42/47ac8aabd19eaad0f10979761d0611a1
contains a more verbose example, also covering the config file
path.

Best regards,

Joerg
#872816#55
Date:
2018-09-23 11:59:25 UTC
From:
To:
Hi Gerog,

Quoting Georg Faerber (2017-08-24 13:33:05)

Yes, please! :-)

 - Jonas
#872816#60
Date:
2022-10-17 06:38:32 UTC
From:
To:
What am I forgetting to do?

It would be nice to choose between a uwsgi and a mod_wsgi config.
#872816#65
Date:
2022-10-21 21:50:48 UTC
From:
To:
So I know I'm making a nuisance out of myself. But I hope that, once I understand what's going on and how to fix it, I can improve the code and/or documentation to make Radicale more useful for future generations.

My DAV folders are permissioned to uid=radicale & gid=radicale & perm=rwxrwx--- (770). It should be documented whether this is too restrictive or permissive, since this _is_ an  Internet-facing service.

The above config  works with the 'recommended' uWSGI implementation. However, I can't figure out which mod_wsgi apache.conf settings will get Radicale to run with radicale:radicale permissions, so Linux quite appropriately refuses to let it access the DAV folders.

One suggestion is to change the DAV folder permissions to www-data:www-data (https://wiki.debian.org/Radicale#Deliver_Radicale_through_Apache) which strikes me as unsafe (fixing wiki documentation is also on my to-do list).

I also discovered the undocumented (!) /etc/default/radicale file, which sets the "--daemon" option. Does this have to be disabled for mod_wsgi?
#872816#70
Date:
2022-10-22 07:23:51 UTC
From:
To:
Hi Borden (and, if still around, Joerg),

Quoting Borden (2022-10-21 23:50:48)

The setup documented as recommended in the radicale package uses uwsgi,
and the main reason for that is that having an apache2 module execute
python code directly means that code gets executed by apache2, not
isolated from apache2.

I doubt I am able to contribute much to this bugreport.  If/when you
guys figure out something you'd like to get added to the radicale
package (and it isn't too involving or exotic) then tell me and I will
sure consider adopting it into the package.  Other than that, I will
leave you to it...


 - Jonas
#872816#75
Date:
2022-10-22 14:16:12 UTC
From:
To:
22 Oct 2022, 03:23 by jonas@jones.dk:
Fair, I understand that this is an off-documented use of Radicale. And I suspect there are some upstream bugs beyond your scope, as the WSGI configs aren't working as advertised.

A couple of questions which I think you can answer and will help me:
1. "secure" permissions for the Radicale store are 660, uid=radicale ; gid=radicale, correct? Can they be more restrictive or should they be more permissive? Should 600 work in the "recommended" setup?
2. /etc/default/radicale only gets read when radicale runs in standalone, correct?
3. The wiki.debian.org/Radicale needs to be overhauled since it doesn't recommend best practices, yes?
#872816#80
Date:
2022-10-22 14:28:24 UTC
From:
To:
Quoting Borden (2022-10-22 16:16:12)

600 could work - not convinced that it should, however: I see no
security risk in allowing write access to a group which has only one
user - except if the sysadmin lets anyone else into that group.

Correct.

Probably - it is a _wiki_ page that I don't care about ;-)


 - Jonas
#872816#85
Date:
2026-03-13 23:27:43 UTC
From:
To:
This seems to be broken again. Some update since 11 March 2026 to the evening of 12 March 2026 has broken /usr/share/doc/radicale/examples/apache2-vhost.conf . At least, I haven't been fiddling with any of the config files.

I know Apache (mostly) works because it lets me connect to https://localhost/radicale , which I've been using for the last 3.5 years until it started throwing 503 errors. I know Radicale is (technically) working because I can run its service and connect to 127.0.0.1:5232.

Unfortunately, that's not good enough because I cannot log in to the latter because it's expecting remote_user credentials and any other authentication scheme fails.

On the Apache side, every attempt to connect is getting this error message:
No such file or directory: AH02454: uwsgi: attempt to connect to Unix domain socket /run/uwsgi/app/radicale/socket (radicale:0) failed

I have python3-radicale & radicale installed, with all their dependencies, recommendations and suggestions.

The fault is probably between apache and uwsgi. But since the stock radicale configuration files and examples aren't working, I wonder whether they need tweaking... again.
#872816#90
Date:
2026-03-14 00:59:09 UTC
From:
To:
Quoting Borden (2026-03-14 00:27:43)

Please don't reuse old bugreports for (potentially) other issues.

What you are describing is likely not specific to radicale but instead
systemd no longer supporting sysV init scripts.

Regardless if you agree with that suspicion of mine, please do file a
new bugreport, as it is much easier to join two bugreports than it is
to meaningfully distinguish and keep track of multiple issues lumped
into one bugreport.

 - Jonas