When radicale 2.x is available in testing, the migration can be
triggered by bumping the module's version.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
With newer version of radicale (>2.1), when configuration is changed, it is not
applied until the application is disabled and re-enabled.
Also make sure that configuration changes don't start a daemon when it is
disabled.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
The default rights file shipped in radicale 2.x package is equivalent
to owner_only. By setting this as our default, we can avoid any change
to the default config.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
The default, remote_user, works ok when using uwsgi.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
Not used with uwsgi, which is enabled for radicale 2.x.
Signed-off-by: James Valleroy <jvalleroy@mailbox.org>
Reviewed-by: Sunil Mohan Adapa <sunil@medhas.org>
- uwsgi service is sufficient to handle radicale2. Disable radicale service for
radicale2.
- Use action utils to deal with uwsgi configuration management.
Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Radicale 1 needs to have /radicale/.well-known/*dav to the URLs where as
Radicale 2 needs to have /radicale to be the URLs. Hence have two separate
apache configuration files.
- Use expr= when setting X-REMOTE-USER header to set the authenticated user name
properly. Without this all users are using a single user '(null)' data.
Reviewed-by: James Valleroy <jvalleroy@mailbox.org>
- Fix code style.
- Keep description and util functions at module level.
- Add license notice to forms file.
- Internationalize and make choice descriptions more informative.
- Since we are trusting the remote user header, it is much safer not
listen on external addresses. We don't that since Apache connects on
internal address.
