Quoting Frank Lienhard (2024-03-17 19:10:43) > On 17.03.2024 00:55, Jonas Smedegaard wrote: > > Thanks for the proposed patch. > > Unfortunately it does not apply to the Debian package. > First: apologies. > I seem to have made a mistake during my dist-upgrade and ended up with > the old init-script, which makes my provided "patch" logically totally > wrong. > > > Please provide a patch against the Debian package (not Devuan). > which makes this request unnecessary, because the devuan package is > identical to the debian package.
Ah, make sense. No need for apology. > > Also, nothing else in the Debian packaging messes with the path > > "$dir/collection-root" - that is left for Radicale itself to handle. > > Can you please test if adequate to replace the 3 instances of > > "$dir/collections" with "$dir" instead? > > So the actual needed patch is quite small and more cosmetic, since it > works out of the box, just w/o logging. And your suggested adjustment > works, too. Looking again, I don't think my suggested change is sensible after all: Might fail to work for a totally clean system where the needed paths are not created yet and assigned appropriate access rights. I haven't tested that, just stared a the logic of the code... > I had a minor problem changing the storage dir. > All works fine with the defaults storage dir > (/var/lib/radicale/collections). When changing it to a different > location in the config file, I only got it working, if I do not generate > the "storage" part from "filesystem_folder = /path/to/storage" beforehand. > > Otherwise I get a write permission problem. Yes, it is tricky to get the access rights in order. I am not in the mood to try guide you there, as I might very well make mistakes in that, just remember that it indeed tricky. I am pretty confident that it works correctly as it is packaged, and also pretty confident that it is possible to reconfigure - but then you are on your own about making the right amount of layers of directories, accessible for the init system and for the inner code spawned by the daome, without leaking access to local filesystem users. So it looks like the only part left of your patch is setting log path in init script. I am hesitant doing that: I seem to recall that it requires custom configuration - that systemd and sysv setups cannot share same default logging configuration, and I therefore chose to provide a working default setup only for systemd. This might actually have changed again with the very newest release of Radicale that I released earlier today. It would be helful if you could double-check using newest package and with *only* the init script change, leaving all other settings at their defaults and with no prior Radicale-related files created on the system - and then check if the logging works as intended. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
