YACReader
YACReaderLibrary server: We need better diagnostics and more failsaves in the headless versions
With the recent release of the 9.8 series and some database format changes it has become evident that we need to improve the diagnostics for adding and updating libraries in YACReader. Especially problematic are:
- Path and permission problems (non-existent or non-writable libraries)
- Installations with no libraries added - this edge case is not properly tested
- Docker installations running YACReaderLibraryServer as root
As this is a frequent cause for user trouble and support requests we should try to make this as foolproof as possible. I am setting the 9.8 series as a possible milestone for this.
User suggestions and/or problem reports are welcome, patches and other help as well.
Unfortunately I don't know C++ so I can't help with these improvements directly, but I just wanted to mention that I've recently completed redesigned my dockerized version of YACReaderLibraryServer so that it drops to a non-root user when running YACReaderLibraryServer and checks directory permissions on run. Hopefully this will help to address the first and and third issues you mentioned for users who want to run a headless server via Docker. However, I do agree about the need for better diagnostics and logging (I am about to create an issue specifically about that).
I debated about having my docker image automatically create a "Comics" library at -v /comics on first run to make things easier for users, but decided not to in order to allow for more user flexibility in terms of library naming, having multiple libraries, etc.
I'm open to suggestions and feedback you might have. Cheers!
@xthursdayx Thank you for the feedback and sorry for the late reply. I have considered just blocking the start of YACReaderLibraryServer when run as root, but did not want to cause a hard break for the docker users. With a solution available that other docker images could just copy this is now a feasible option. The question which exact settings a Docker image should use for best user experience is a tricky one and there is probably more than one opinion. Maybe it could be possible to discuss this among the authors of the YACReaderLibraryServer Docker images that are actively maintained right now?
@selmf no worries at all about the delay.
I agree that not blocking running as root is probably the best idea (for now) since some other YACReaderLibraryServer docker images are set up to run that way. I haven't been in touch with any of the other YACReaderLibraryServer Docker image maintainers (probably not a bad idea), but I've kind of "gone down the rabbit hole", and spent the last two weeks completely redeveloping my own container which I'm close to launching.
Once launched it will run YACReaderLibrary Server using s6-overlay with a non-root service user and a be a multi-arch (automatically pulled to match the end user's system - amd64, arm64, or amrhf), and will allow the user to choose the compression backend their container is built with, either unarr (the default/latest option) or the p7zip. Both are working well now, though I could use some help testing on arm systems.
My image will likely be slower to start than some of the other YACReaderLibraryServer docker images I've seen since it relies on s6 rather than an entrypoint.sh or system.d and it's built on the Ubuntu LTS cloud image (rather than Alpine, for example), however, I've gotten each variant down in size to around ~130mb (compressed), which I feel fine about, and they seem to function fast enough for my needs at least.
I'm pretty close to launching it and am using a Github Workflow to build and publish both the images and the manifest, since it's a fairly complicated set up and more that Docker Hub builds can handle.
I'll report back once I'm able to get everything up on Docker Hub. If you're still interested after that, we can talk about including a docker image (or images) in the YACReaderLibrary CI process, and if the docker can or should be improved in any way.
Of course, to get back to the original point, better diagnostics and logging would help with this along the way when working to implement headless docker containers.