Howto is available in the wiki: http://wiki.nethserver.org/doku.php?id=userguide:savapage
For discussion this thread will stay active
4 Likes
Do we need to discuss this part of the howto?
1 Like
Just formatted a bit and wikified the post. I hope many members help you to improve it!
Great job! You deserve a Venkman
2 Likes
The developer of savapage was thinking out loud about the cups.service being overwritten by savapage. His suggestion to solve this is like:
Savapage is a wrapper on top of CUPS. It takes over all permissions for printing. So instead overwriting the NS7 cups.service, create a savapage.cups.service and disable the default NS7 cups.service.
This has a few advantages:
The cups.service doesn’t have to be overwritten and when there is an update for the printserver module (which ships CUPS and installs the cups.service) the sups.service remains disabled.
I am not a dev, and would like input (@giacomo @davidep @stephdl @areguera) if this is a good idea.
1 Like
systemd provides a mechanism to override a unit configuration. In other words, if savapage needs to tweak cups.service unit configuration it can just drop a file under cups.service.d/ directory.
This is explained in the official systemd docs.
1 Like
Hi @davidep thnx for the response. What would be the impact if the printserver module gets an update and cups gets a new version?
If anyone using NethServer decides to use SavaPage, you can assume default CUPS isn’t used anymore. SavaPage is wrapper on top of CUPS that takes over all permissions and accounting. So I think avoiding overwriting the service by CUPS when it gets an update is the way to go.
Or am I missing something here?
1 Like
I don’t know what savapage does. Only pointed out that systemd provides an override mechanism. You could also disable cups unit entirely and mark it as Conflicting with savapage in systemd. Why not installing nethserver-cups at all?
No no… SavaPage uses cups… it sits on top of cups. But it overwrites the cups service:
From the SavaPage issue tracker
cupsd is the scheduler for CUPS. When it’s run from systemd some systems
pass the -l parameter so cupsd is run on demand by socket and path
activation. The advantage of this setup is that CUPS is activated when
needed, saving precious boot time and resources, and deactivated again
after being idle for a while. This lazy activation scenario is efficient
for desktop systems that print occasionally and for which printing is
not time critical. However, dedicated print systems like SavaPage, that
intensively use IPP to communicate with CUPS, need CUPS to be full-time
activated.
Therefore we install a custom systemd cups.service unit in
/etc/systemd/system/ to override the default shipped with the CUPS
package. This custom unit starts cupsd with the -f parameter so it runs
steadily in the foreground (without dependencies for cups.socket and
cups.path).
2 Likes
So… does the solution suggested by the SavaPage developer make sense? Or is it against the NS philosophy on how to handle systemd services?
Can we expect any form of problems if the SavaPage install disables the default CUPS service and creates it’s own savapage.cups.service?
As said, the idea is that IF the NS printermodule (that installs CUPS and cups.service) gets an update, the savapage install doesn’t break, and the SavaPage install doesn’t change the default cups.service (it disables the service instead)
I think we can safely assume that if someone installs SavaPage to manage all printing, standard printqueue’s are not used anymore, all printing will be handled by SavaPage.
I will ask confirmation when de-installing SavaPage, the default cups.service will be reactivated.
It would be nice if the install howto gets tested by others. Please confirm or add suggestions for changes.
1 Like
IIRC systemd has also a priority mechanism: if you install the .service file under /etc/systemd/system it overrides /usr/lib/systemd/system.
Anyway I’d tweak the unit file with the method I said above: cups.service.d/.
ExecStart=...whatever