Hi everybody,
just jumping in this thread as I actually upgraded from Calibre 2.x to Calibre 3.1.1 and stumbled across the various architectural changes in the 3.x version.
In the 2.x Version I used multiple calibre-server instances bound to different ports with different url-prefixes and different virtual-libraries which in the new version is quite different / harder / even not possible(?) to implement.
Background and solution in V2:
- I use one big calibre library where all books are in.
- For accessing the library from the internet I use the standalone calibre-server running on a headless linux server (virtual) machine. This should ever be read only!
- I have different groups of persons who should see different sub-sets (=virtual libraries) of the whole content (a simple example: Adult and Non-Adult content)
- An Apache Server exists since many years which listens on Port 443 and acts as a central web portal which serves other services (nextcloud for example) beside and also calibre-server (WebFrontend and OPDS are in use).
- The portal in Apache is completely configured to use Basic Auth with an LDAP Backend for centralized user / group management, so at this point no unauthorized access also (but not only) to calibre is implemented. Therefore it isn't really neccessary to use the authentication mechs of calibre.
- In Apache the different calibre-instances are included by ReverseProxy directives pointing to the different url-prefix/port combinations of the different calibre-server instances.
- The Apache portal now gives access to the different calibre-urls based on the logged in LDAP User.
- The router just forwards port 443 to this Apache Server, no forwarding to the calibre-server instances Ports.
So far so good, this worked as expected.. the different LDAP Users got different virtual libraries in the portal and so - for example - children didn't get access to adult content.
Now I wanted to adopt this behaviour to V3 and came across these issues which I could partially solve:
- No --virtual-libray Option in V3
Solved by creating the calibre userdb, a few different (technical) users with restricted access to other parts of the library. These users don't have write access.
- Apache LDAP login now conflicted with the now enabled Basic Auth of calibre-server in the backend
Solved by inserting "RequestHeader set Authorization..." in the responsible Apache directive with the ReverseProxy for calibre
Now I stuck at the point to start multiple calibre-server instances for presenting different url prefixes that map to different calibre-users and so to different virtual libraries.
As mentioned in this thread, it is not possible to start different server instances any more?? When one calibre-server is running and I want to start a second one (with different options but the same big library) I get this error:
"Another calibre program such as another instance of calibre-server or the main calibre program is running. Having multiple programs that can make changes to a calibre library running at the same time is not supported"
The part "that can make changes to a calibre library" is the important one as the calibre-server instances (in my case) never ever will do any changes as they should just give read-only access to the library.
Isn't there any option to tell calibre-server it should run in a somehow "global read-only" mode (as this would be absolutely enough)? In this case, data-loss can't occour with concurrent writes. I just tried "--disable-local-write" but this didn't work, the error remains.
IMHO there could be different solutions to solve this:
- Give an option like "force (I know what I do)" or "global readonly" to the calibre-server so it will be possible to run different instances like in V2
- Get rid of the "url-prefix" and let the server automatically determine the prefix (as many many other web-services do today, nextcloud for example). So there would be no need to start different servers, one would be enough. The different portal URLs could then be proxied to just one single calibre-server in the backend. Access then will be realized by using different "RequestHeader set Authorization" directives in Apache.
Or did I miss something? Or does anyone have another hint how I could achieve the V2 solution in V3?
Greetings and thx in advance!
Snoopy