scheduler/org.cups.cupsd.service.in: ensure that sssd is up when cups starts #5551
Conversation
… starts When the group defined in the SystemGroup directive is provided via sssd, and sssd is not available when cups starts, cups will crash. This patch makes cups start after sssd when both are present in the machine. (Issue apple#5550)
|
If there is a After= dependency to the main repository, then the default from Fedora should also included: After=network.target ypbind.service CUPS requires a working network connection (to reach network printers), and sssd is just one possible name service, so ypbind should also be included. I would request to change the line to After=network.target ypbind.service sssd.service |
|
@imsedgar Thanks for raising the issue up! I added that patch in Fedora some time ago, but I was not sure if it is a issue for upstream. The patch is for users, which use NIS for getting users/groups from other machine and put NIS user/group into SystemGroup. (But since NIS is quite old and not very used, I was not sure about reporting upstream). |
|
@zdohnal @vtapia In general I think that only "After=network.target" is necessary, because cups is a service that needs only access local files and the network. Packages (rpm, deb) can create a local user for this local service. This service is independent from the same service on other computers, there is no need to use the same uid, gid, username or group name between different hosts. So I think it is preferable not to share the user and group between different hosts, but keep it local to each host. Because of this I think it is a bad idea to share it in nis, ldap, active directory, etc. For local use, I think, if sssd is configured but not running, then the name resolution interfaces will access files in /etc directly. |
When the group defined in the SystemGroup directive is provided via
sssd, and sssd is not available when cups starts, cups will crash. This
patch makes cups start after sssd when both are present in the machine.
(Issue #5550)