Other ports define USERS= , GROUPS=, which makes sure the user is present on a running system. Calibre doesn't do this? At least I did not find a mapping in UIDs in the ports tree root, https://cgit.freebsd.org/ports/tree/UIDs, the same can be said for the GIDs
Is a seperate user needed for calibre? Does it bring some system service that would run as that seperate user? Not every port needs a seperate user. One is only defined for ports that need one
Of source :), calibre uses it in the service script included in the port. Calibre is more than a desktop app, it can also be used as headless database backend for books. https://cgit.freebsd.org/ports/tree/deskutils/calibre/files/calibre.in
Hi! Thanks for taking the time to report this. Yes, calibre port provides a server part, that can be ran as a daemon and that one uses a system user to run. Although I maintain the port I have never used such functionality except testing it sometime ago. When I started maintaining the port that part was already present and I did not change it too much. Adding a reserved user for the calibre port, which would be added for anyone installing the port, even if the user is never going to use the server part is not the best option. While I have no proof of it, my gut feeling is that the majority of the people using calibre are not using the server part. So, while your suggestion makes sense, I need to think a little about this. Maybe hide the user creation and installation of the daemon startup script behind an option or just add instructions on how to create the correct user in pkg-message. The pkg-message solution makes sense since there is really no difference between a reserved uid and one created manually by the user with adduser(8) for any practical purposes. Another thing I will consider is that the ports tree should get SUBPACKAGES features in the near future and this would be a perfect application for this. The user creation and startup script could be packaged with a separate subpackage. (flavors are not meant for this kind of thing and it would be an abuse of them) What I would not like is adding a reserved user to the port/pkg that maybe would be really used by just a small part of the users. SO I need to think a little while about the best path for this situation.
Hi Guido! Thanks for taking the time replying here :). Adding and reserving a user is never lost, it can be reused when subpackages are a thing. I rather think that calibre will be the exception if it does not ship with a user defined in UIDs, GIDs as the service script refers to it (which it should to run unprivileged) and pkg-message asks to install it. Look at the git or even git-lite flavor for example, it ships with the user git_daemon, I think nobody of the both of us will be using it atm as a service, at least I am not, I just use "git" :) Calibre as a database backend for books is not so uncommon as you think. Its a very popular backend for calibre-web which I will be porting soon. This is the main reason I found this port in our tree. I'm happy to give an update to the rc script and do the general work and attach that patch here to "get it in good shape" for database use only. Happy to hear back from you, let it simmer a bit :)
(In reply to Dries Michiels from comment #4) I maybe failed to convey what I would not like, but I can live with it, is adding a system user created by the port on installation that may well not be actually needed by at least some people installing the port. The fact that a lot of ports do provide users that may not be used by a significant part of the users does not mean that it is a good idea. In other words, as a general principle, the fact that everybody is doing it does not mean it is right, or even correct. But, as you notice we are providing a startup script for it referencing a user, so we could as well provide one, which does make sense. Also, calibre 7.0 just came out, so I'm going to see if adding user together with the update. I only need a little time to do the update and test. I'd also like to point out that nobody has statistics on installed ports on final users machines, and even less data on how the software is used, so any valuations about how many people are using the server capabilities of the calibre ports are just guesses and hunch feelings. I expressed my hunch feeling just to explain why I never cared to look depend into this, not as a justification for keeping not providing a user. Add to this that I have never used the calibre server functionality (only tested running those once), and this explains why I did not even ever notice the missing user. I was not trying to justify not adding it, only explaining why it never occurred to me in the past.
Hi, I have the update almost ready and I'm planning to add a user. Unluckily while testing I noticed the startup script has multiple glitches. First of all the user created ha "/nonexistent" home directory (I would not know what else to set for it) and the rc script fails to run with such a value. It is passed as the HOME env variable to the server, not sure what it is used for. Also, calibre by default created its library directory as "Calibre Library" (notice the space), the rc script has issues with this. First the "required_directory" variable is checked with a shell for cycle, that separates on the space. Then even disabling that check, it fails to run also separating the path. I tried adding backslashes for escaping and extra quoting, but it is not helping much. There is also a problem with access permissions, that need to be tailored to the server. I have the calibre library owned by my own user, not calibre. At this point I'm not sure that creating a system user for the daemon was the intended way to use this, but it was intended to be configured by the user to run at their own user, who own the calibre library. That would work fine and is aligned with how the script was intended to be used (I did not write it, it was proposed to me years ago for inclusion.). The default user of calibre is there just as an example and fallback, not as the intended way to use it. How are you using it? what is your intended objective? Could you provide an improved script that could replace the current one providing correct support for a system calibre user? With the current script shipping a system user would not help a new user, in fact would make things even more confusing.
I'm thinking about this. As I said, the rc script was added with the idea that users would configure it to use their existing user (the one they run calibre as on the desktop, and who already owns the library files). The "calibre" default was added just because, well, a default was required. I don't know what kind of usage and purpose for the calibre server you have in mind, but with things a they are simply registering a calibre user would not help in any way. The rc script would fail out of the box anyway, with even more confusing errors, about missing home directory, missing library, and permissions (in that order, once each is solved). With the present situation a user reading hte pkg-message would at least have some indication (the pkg-message could be improved. Adding a system user for calibre could be part of an improvement but by itself makes no sense with the startup script as is. I'm going to update the port to version 7.0.0 shortly without adding the user for the reasons above. I will try to imp[rove the pkg-message a little. If you can describe the usage model you have in mind for the server functionality, maybe it could make sense to modify the rc script and provide a suitable system calibre user for it. But if creating a user is just one of many steps required to make it work (move library, change permission/ownership), I don't really see the advantage, since it could be better for users to be able to customize all that to their preference.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=24707c92fd8b63030be3fe4895e11fbff9651bac commit 24707c92fd8b63030be3fe4895e11fbff9651bac Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2023-11-18 15:17:40 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2023-11-18 15:17:40 +0000 deskutils/calibre: Update to 7.0.0 - Add dependencies, and bump some minimum requirements - Improve pkg-message information about the server functionality and the included rc script [1] PR: 275102 [1] deskutils/calibre/Makefile | 19 +++-- deskutils/calibre/distinfo | 14 ++-- .../files/patch-src_calibre_db_cache.py (new) | 11 +++ .../files/patch-src_calibre_db_notes_exim.py (new) | 11 +++ deskutils/calibre/files/user-agent-data.json | 96 +++++++++++----------- deskutils/calibre/pkg-message | 7 +- deskutils/calibre/pkg-plist | 14 +++- 7 files changed, 105 insertions(+), 67 deletions(-)
I see two use cases for this port: 1) Being used as desktop app. The logged-in user starts the program by clicking on a desktop shortcut or from the cli. This use case creates a database, owned by the user that started the program and under the user's home directory. (@madpilot, can you confirm this is true? database is created under your home directory on your pc) For this, the port works fine as is. 2) Being used as database back-end. The service is used to start the daemon (database) to listen for queries and operations. This creates the database under /var/db/calibre and is owned by the system user "calibre" (to be created). The daemon is being run as a service and is ran under the system user "calibre". For this, the port rc scripts needs to be adjusted. If you give consent for use case 2, I'm happy to attach a patch with changes to the rc script that supports this use case. I even think both use cases can be used at the same time without interference. (they will use a separate database located elsewhere)
If changing the current rc-script, "calibre.in", is unwanted for POLA reasons, then a "calibre_server.in" script can be shipped. Although, I think changes to an rc script can be done with a corresponding UPDATING entry, which I'm happy to include if you prefer the route of shipping a separate rc script to support the server functionality.
(In reply to Dries Michiels from comment #10) which I'm happy to include if you prefer the route of adjusting the current rc script*
(In reply to Dries Michiels from comment #9) > 1) Being used as desktop app. The logged-in user starts the program by > clicking on a desktop shortcut or from the cli. This use case creates a > database, owned by the user that started the program and under the user's > home directory. (@madpilot, can you confirm this is true? database is > created under your home directory on your pc) For this, the port works > fine as is. The port was mainly created for this use case. On first start calibre asks where to put the library, if I remember correctly the proposed default is "~/Documents/Calibre Library" (with a space in it), but the users can point wherever he want, can adopt an existing library, and move it later. Obviously the user needs to have access to where the library is being put. > 2) Being used as database back-end. The service is used to start the > daemon (database) to listen for queries and operations. This creates > the database under /var/db/calibre and is owned by the system user > "calibre" (to be created). Have you verified this? I mean how are you launching this backend and creating this database? AFAIK calibre just expects the library to already exist in server mode and being pointed at it. Anyway this part could be handled with instructions in pkg-message on how to configure the library. User intervention for configuring server type software is normal. You could add a custom command to the rc script to setup the directory in /var/db/calibre and create an empty library there (if calibre provides such functionality via command line) > The daemon is being run as a service and is ran under the system user > "calibre". For this, the port rc scripts needs to be adjusted. It is not clear to me if what you describe in 2) is how things work launching calibre server manually or how you'd like them to work out. In the second case, are you sure your expectations align with how calibre server is meant to work by the upstream? IF the rc script via custom command created the required files in /var/db/calibre then the present rc script is almost ready, and we could get by just adapting the defaults, with no loss of functionality for people wanting to run the server from their home directory, once they adapt the values. To get this (IF calibre is able to create an empty library in an arbitrary location via command line), you can add a calibre user in UIDs (with related group in GIDs) with his home directory set to /var/db/calibre, add the required variables in the calibre ports and and have the custom rc script command create and properly populate that, and then adapt the rc script defaults. Any step that cannot be automated will require proper instructions in pkg-message. (In reply to Dries Michiels from comment #10) > If changing the current rc-script, "calibre.in", is unwanted for POLA > reasons, then a "calibre_server.in" script can be shipped. Although, > I think changes to an rc script can be done with a corresponding > UPDATING entry, which I'm happy to include if you prefer the route > of shipping a separate rc script to support the server functionality. As I said above, the rc script does not need big changes, what is needed is to define the expected setup for the "system user daemon" functionality. ON the other hand I'd like to have the rc script keep the ability to serve via a user's home directory private library, for users wanting that. This could not even need UPDATING instructions, since such users are already configuring rc script variables.
(In reply to Dries Michiels from comment #11) I'm brain storming here with you on how this can be done. I have put my best ideas in commnet #12 I'm not using calibre server mode, so, if you are using it, you're in a better position to provide the required glue [1] and properly test it. The biggest issue with the rc script I have is I found no way to make it work when the library path has spaces in it. But I'm not requiring you to fix this! :) I hope my insight are helpful. [1] which, as stated, is mostly a rc script custom command and adapted defaults.
(In reply to Guido Falsi from comment #12) It is not clear to me if what you describe in 2) is how things work launching calibre server manually or how you'd like them to work out. => This is how I would like it to work :) I'll take a stab at the rc script this weekend.