[Freedombox-discuss] Tracking down the radicale problem.

[A. F. Cano]

On Wed, Mar 27, 2019 at 08:46:52AM +0100, Jonas Smedegaard wrote:
> Quoting A. F. Cano (2019-03-27 04:18:32)
> > chown radicale.radicale /var/lib/radicale
> > chown radicale.radicale /var/lib/radicale/collections
> > chown radicale.radicale /var/lib/radicale/collections/afc
> 
> Safer to delimit user and group with ":" - e.g. like this:
> 
>   chown radicale:radicale /var/lib/radicale

Thanks for this tip.  Found the reason here:

https://www.gnu.org/software/coreutils/manual/html_node/chown-invocation.html#chown-invocation

I've been using owner.group for years and years.

> 
> > And no wonder, I also have to change /etc/radicale/logging per
> > 
> > https://wiki.debian.org/Radicale
> 
> Please notice that above wiki page documents a different "more 
> lightweight serving directly by Radicale [...] discouraged and not well 
> tested".

Yes, I tried every method I could find.  I happened to find that one
first.  It didn't work of course, so I went on to configure it proplerly
with uwsgi.

> ...
> If you have configured Radicale to run with uWSGI (only, not also itself 
> listen on same port!) then you should first check the Apache2 logs if it 
> received the requests you expect it to.  And then check uWSGI logs if it 
> received the requests Apache2 was configured to proxy.

The uwsgi logs only show the staring of the processes:

Sun Mar 31 14:19:05 2019 - spawned uWSGI master process (pid: 945)
Sun Mar 31 14:19:05 2019 - spawned uWSGI worker 1 (pid: 1390, cores: 4)
Sun Mar 31 14:19:05 2019 - spawned uWSGI worker 2 (pid: 1391, cores: 4)
Sun Mar 31 14:19:05 2019 - spawned uWSGI worker 3 (pid: 1392, cores: 4)

The example file I used

/usr/share/doc/radicale/examples/apache2-vhost.conf

and copied to

etc/apache2/sites-available/events.example.org.conf

per the instructions I found earlier either has a problem with the
$(DOMAIN) or $(_DOMAIN) variables, or I'm not understanding how these
are used.  At first I was getting file names in /var/log/apache2 of
the form <host-name>.$(DOMAIN)-access.log and then when I changed
the second line below

Define _DOMAIN example.org
Define _HOST event.${DOMAIN}

to 

Define _HOST event.${_DOMAIN}

the file names were now correct.  In the copied version "event" was
changed to the system name of that computer and example.org was
changed to the internal domain of the system.  Yet, $(DOMAIN) is used
later in the file and is apparently not set.  This is what apache2
claims:

Sun Mar 31 14:18:49.243657 2019] [core:warn] [pid 654] AH00111: Config
variable ${DOMAIN} is not defined.

Not sure if this is important.  It's only a warning.

> > Does anyone have any idea what I'm missing? Somewhere I read that the 
> > data needed to be migrated in the upgrade from radicale 1.x to 2.x but 
> > it didn't say how.
> 
> It is mentioned in /usr/share/doc/radicale/NEWS.Debian.gz
> 
> Where did you try look for the information?

I did a web search.  It probably came up with the NEWS.Debian.gz file
above.

I went looking further and found

https://radicale.org/1to2/

Per that page installed radicale 1.1

dpkg -i python-radicale_1.1.6-4_all.deb

And now I'm finding that the python ecosystem is quite unique to say the
least.  I had to go find where the file to execute is as it wasn't found
in the usual paths.  Dpkg --contents /var/tmp/python-radicale_1.1.6-4_all.deb
told me what I had to run was this:

python  /usr/lib/python2.7/dist-packages/radicale --export-storage
/var/lib/radicale/collections/afc

but it doesn't work:

Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File
    "/usr/lib/python2.7/dist-packages/radicale/__main__.py", line 36, in <module>
    from . import (
ValueError: Attempted relative import in non-package

I hope this is not a case of incompatible python versions being used and
that I won't have to uninstall everything radicale 2.x or python 3 in
order to run the export-storage option.

Actually I'm surprised that the FreedomBox upgrade didn't do the data
migration before upgrading to 2.x.  If it did, then the problem is
something else.  All along I've been assuming (because that's what
worked in 1.x) that the user data was in
/var/lib/radicale/collections/<user>/.  Where is the user data stored in
radicale 2.x? Is it human-readable?

How do I run radicale 1.1 to convert the user data?

Thanks.

Augustine